Relationship and security in online social and professional networks and communities

ABSTRACT

A method is provided for evolving a defined online existing relationship between a first member and a second member, the online existing relationship defined by a plurality of existing relationship features for use in managing network interaction on a communications network between the first member and the second member. The method comprising: receiving a new online relationship having new relationship features such that the new features are different from the existing relationship features, the new relationship features being characteristic of the new relationship; aggregating the existing relationship features and the new relationship features as aggregate relationship features a combination of the existing relationship features and the new relationship features in order to define an aggregate relationship; storing the aggregate relationship features in a storage as relationship data; and accessing the relationship data in order to determine whether a selected network interaction from one of the members is permitted.

CROSS-REFERENCE TO RELATED APPLICATIONS

This application is a Reissue Application of Continuation U.S. Pat. No.8,364,753 issued on Jan. 29, 2013, which is a continuation of earlierfiled non-provisional application having U.S. application Ser. No.12/619,451 filed 11/16/2009, now abandoned which in turn claims priorityto U.S. Provisional Patent Application No. 61/272,010 filed 08/06/2009and all of which is, the contents of which are incorporated herein byreference in their entirety.

FIELD OF THE INVENTION

This invention relates to configuration of networked entities forcoordination of interaction between the networked entities.

BACKGROUND OF THE INVENTION

In today's multifaceted society, there are a number of industries (e.g.healthcare) that can be characterized as having a particularlyfragmented workforce—in healthcare from physicians to nurses to practiceadministrators—that are extremely busy in their day to day activities.Day to day work for individuals in today's industries can be highlyirregular and unpredictable, and with so many different parts working inisolation there are limited opportunities for people to be exposed toone another. Further, with few networks supporting these people orgroups in reaching out and connecting with each other, it's easy forthem to become isolated. All of this makes it very difficult forindustry professionals to get in touch with who they want when they needto, to stay in touch with colleagues and co-workers within and/orbetween different industries, and to coordinate productive interactionswith each other.

Social and professional networking is valuable to business professionalsand healthcare professionals of all types. When people become members ofsocial and professional online networks, they need to connect with othermembers in order to share information with, interact with, and networkthrough those members. In cases where people are connecting to businessprofessionals, business relationships are important and need to beentered into with care. Each relationship is different, eachrelationship has a level of trust, and people do not want to connectonline with each of their professional contacts in the same way.Ultimately, it's not a one size fits all world when it comes toconnecting online and the representation electronically (i.e. online) ofthe mixture of real world business and professional relationships isproblematic using today's electronic relationship models.

Accordingly, in the current one size fits all world, a system is neededthat enables community members to connect with their businessconnections in a way that represents their multifaceted life with theplurality of other members in the community (both known and unknown tothe community member) because the members do not want to share the sameinformation, communicate and interact in the same way, nor enable peopleto network through them in the same way, in view of real-worldrelationships. An example of this is that not everyone is “best” friendswith every other person they have met in their real-world life. Thereare varying degrees of friendship/acquaintance in the real-world andthere is a need to represent this in the online/electronic forum,amongst other possible types of relationships between people.

SUMMARY OF THE INVENTION

It is an object of the present invention to provide an benefit and ruleconfiguration environment to obviate or mitigate at least some of theabove-presented disadvantages.

In the current one size fits all world, a system is needed that enablescommunity members to connect with their business connections in a waythat represents their multifaceted life with the plurality of othermembers in the community (both known and unknown to the communitymember) because the members do not want to share the same information,communicate and interact in the same way, nor enable people to networkthrough them in the same way, in view of real-world relationships. Anexample of this is that not everyone is “best” friends with every otherperson they have met in their real-world life. There are varying degreesof friendship/acquaintance in the real-world and there is a need torepresent this in the online/electronic forum, amongst other possibletypes of relationships between people. One method is provided forevolving a defined online existing relationship between a first memberand a second member, the online existing relationship defined by aplurality of existing relationship features for use in managing networkinteraction on a communications network between the first member and thesecond member. The method comprising: receiving a new onlinerelationship having new relationship features such that the new featuresare different from the existing relationship features, the newrelationship features being characteristic of the new relationship;aggregating the existing relationship features and the new relationshipfeatures as aggregate relationship features a combination of theexisting relationship features and the new relationship features inorder to define an aggregate relationship; storing the aggregaterelationship features in a storage as relationship data representing,the aggregate relationship defined by the relationship features; andaccessing the relationship data in order to determine whether a selectednetwork interaction from one of the members is permitted in view of atleast one of the corresponding aggregate relationship features of theaggregate relationship, and facilitating the selected networkinteraction between the members when determined as permitted; whereinsaid at least one of the corresponding aggregate relationship featuresof the aggregate relationship is used to define as permitted at leastone of the network interaction type, the network interaction content, orthe network interaction format.

A first aspect of the present invention provided is a method forevolving a defined online existing relationship between a first memberand a second member, the online existing relationship defined by aplurality of existing relationship features for use in managing networkinteraction on a communications network between the first member and thesecond member, the method comprising the steps of: receiving a newonline relationship having new relationship features such that the newfeatures are different from the existing relationship features, the newrelationship features being characteristic of the new relationship;aggregating the existing relationship features and the new relationshipfeatures as aggregate relationship features a combination of theexisting relationship features and the new relationship features inorder to define an aggregate relationship; storing the aggregaterelationship features in a storage as relationship data representing theaggregate relationship defined by the relationship features; andaccessing the relationship data in order to determine whether a selectednetwork interaction from one of the members is permitted in view of atleast one of the corresponding aggregate relationship features of theaggregate relationship, and facilitating the selected networkinteraction between the members when determined as permitted; whereinsaid at least one of the corresponding aggregate relationship featuresof the aggregate relationship is used to define as permitted at leastone of the network interaction type, the network interaction content, orthe network interaction format.

A further aspect provided is a method for evolving a defined onlineexisting relationship pair between a first member and a second member,the online existing relationship pair defined by a first existingrelationship role assigned to the first member having a plurality offirst existing role features for use in managing network interaction ona communications network between the first member and the second member,and a second existing relationship role assigned to the second memberhaving a plurality of second existing role features for use in managingthe network interaction between the first member and the second member,the method comprising the steps of: receiving a new online relationshippair having a new first relationship role and a second new relationshiprole, such that the corresponding first new role features and the secondnew role features are different from the first existing role featuresand the second existing role features, the first new role features andsecond new role features being characteristic of the new relationshippair; aggregating the first existing role features and the first newrole features as aggregate first role features being a combination ofthe first existing role features and the first new role features inorder to define an aggregate first role; aggregating the second existingrole features and the second new role features as aggregate second rolefeatures being a combination of the second existing role features andthe second new role features in order to define an aggregate secondrole; storing the aggregate first role and the aggregate second rolewith their associated aggregate features in a storage as relationshipdata representing an aggregate relationship pair defined by theaggregate roles and their corresponding aggregate role features; andaccessing the relationship data in order to determine whether a selectednetwork interaction from one of the members is permitted in view of atleast one of the corresponding aggregate role or aggregate role featuresof at least one of the aggregate first role or aggregate second role ofthe aggregate relationship pair, and facilitating the selected networkinteraction between the members when determined as permitted; whereinsaid at least one of the corresponding aggregate role or aggregate rolefeatures of at least one of the aggregate first role or aggregate secondrole of the aggregate relationship pair is used to define as permittedat least one of the network interaction type, the network interactioncontent, or the network interaction format.

A further aspect provided is a method for evolving a defined onlineexisting relationship pair between a first member and a second member,the online existing relationship pair defined by a plurality of existingrelationship features for use in managing network interaction on acommunications network between the first member and the second member,the method comprising the steps of: receiving a new online relationshippair having corresponding new relationship features different from theexisting relationship features, the new relationship features beingcharacteristic of the new relationship pair; combining the existingrelationship features and the new relationship features to generatecombined relationship features by adding a new feature from the newrelationship features to the existing relationship features, such that aminimum number of the existing relationship features remain as part ofthe combined relationship features; storing the combined relationshipfeatures in a storage as relationship data representing the newrelationship pair for the members defined by the correspondingrespective combined relationship features; and accessing therelationship data in order to determine whether a selected networkinteraction from one of the members is permitted in view of at least oneof the corresponding combined relationship features, and facilitatingthe selected network interaction between the members when determined aspermitted; wherein at least one of the corresponding combinedrelationship features of the new relationship pair is used to define aspermitted at least one of the network interaction type, the networkinteraction content, or the network interaction format.

A further aspect provided is a method for evolving a defined onlineexisting relationship pair between a first member and a second member,the online existing relationship pair defined by a first existingrelationship role assigned to the first member having a plurality offirst existing role features for use in managing network interaction ona communications network between the first member and the second member,and a second existing relationship role assigned to the second memberhaving a plurality of second existing role features for use in managingthe network interaction between the first member and the second member,the method comprising the steps of: receiving a new online relationshippair having corresponding first new role features and the second newrole features different from the first existing role features and thesecond existing role features, the first new role features and secondnew role features being characteristic of the new relationship pair;combining the first existing role features and the first new rolefeatures to generate combined first role features by adding a newfeature from the first new role features to the first existing rolefeatures, such that a minimum number of the existing first role featuresremain as part of the combined first role features; combining the secondexisting role features and the second new role features to generatecombined second role features by adding a new feature from the secondnew role features to the second existing role features, such that aminimum number of the existing second role features remain as part ofthe combined second role features; storing the combined role features ina storage as relationship data representing the new relationship pairfor the members defined by the corresponding respective combined rolefeatures; and accessing the relationship data in order to determinewhether a selected network interaction from one of the members ispermitted in view of at least one of the corresponding combined rolefeatures, and facilitating the selected network interaction between themembers when determined as permitted; wherein at least one of thecorresponding combined role features of the new relationship pair isused to define as permitted at least one of the network interactiontype, the network interaction content, or the network interactionformat.

A further aspect provided is a method for defining an onlinerelationship pair between a first member and a second member, therelationship pair including a first relationship role assigned to thefirst member having a plurality of first role features for use inmanaging network interaction on a communications network between thefirst member and the second member, and a second relationship roleassigned to the second member having a plurality of second role featuresfor use in managing the network interaction between the first member andthe second member, the method comprising the steps of: assigning thefirst relationship role to the first member such that the first rolefeatures are characteristic of the first relationship role; assigningthe second relationship role to the second member such that the secondrole features are characteristic of the second relationship role, suchthat the second member must confirm the second relationship role inorder for the first member to be able to use the first relationship rolein the network interaction between the first and second members; storingthe first role and the second role with their associated role featuresin a storage as relationship data representing the relationship pair;and accessing the relationship data in order to determine whether aselected network interaction from one of the members is permitted inview of at least one of the corresponding relationship roles or rolefeatures of at least one of the first role or second role of therelationship pair, and facilitating the selected network interactionbetween the members when determined as permitted; wherein said at leastone of the corresponding relationship roles or role features of at leastone of the first role or second role of the relationship pair is used todefine as permitted at least one of the network interaction type, thenetwork interaction content, or the network interaction format.

BRIEF DESCRIPTION OF THE DRAWINGS

Exemplary embodiments of the invention will now be described inconjunction with the following drawings, by way of example only, inwhich:

FIG. 1 is a block diagram of relationship network environment;

FIG. 2 shows a block diagram of an example computing device forimplementing components of the system of FIG. 1;

FIG. 3 shows example interactions between members in the relationshipmanagement system of the system of FIG. 1;

FIG. 4 shows an example claim of the environment of FIG. 1;

FIGS. 5a,5b,5c show example relationship pairs of the members of FIG. 1;

FIG. 6 shows example member roles of the members of FIG. 1;

FIG. 7 shows an example relationship gate of the system of FIG. 3;

FIG. 8 shows a relationship matrix used by the relationship gate of FIG.3;

FIG. 9 is a further embodiment of the gate of FIG. 8;

FIG. 10 is an example operation of the gate of FIG. 9;

FIG. 11 is an example of banding of the relationships of FIG. 1;

FIG. 12a is a further embodiment of the relationships of FIG. 1;

FIG. 12b is an example modification of the relationship of FIG. 12a;

FIG. 13 shows an example configuration of the administration system ofFIG. 1; and

FIG. 14 shows an example operation of the administration system of FIG.13.

DETAILED DESCRIPTION OF THE EMBODIMENT(S)

Relationship Environment Network 10

Referring to FIG. 1, relationship and security in online social andprofessional networks and communities is provided by a relationshipenvironment network 10. The network 10 provides for members 20 (i.e.registered users) and non-members 24 (i.e. unregistered users) of arelationship administration system 26 to connect/communicate 14 over acommunications network 11 with each other in ways that enhance theirreal world relationship, such that their online accounts (relationshipdata 15, otherwise known as a configured relationship matrix 15 for theplurality of members 20 and their optionally assigned relationship roles12a,b) share information electronically and the members/non-members 20,24 interact with each other electronically in accordance with a definedconnection/shared relationship (e.g. relationship pair 12) defined andadministered by the relationship administration system 26. It isrecognised that both members 20 and non-members 24 will hereafter bereferred to generically as members 20 for the sake of simplicity, suchthat members 20 can be of a type registered or unregistered (i.e.non-members). The administration system 26 provides for a plurality ofdefined relationship pairs 12 assigned to selected pairs of members 20to adapt and change over time through amendment in the one or morerelationship roles 12a,b (or to their commonly assigned relationshipfeatures 18 that are not assigned to any particular role 12a,b) assignedto the members 20 for representing any changes in the professionaland/or personal relationship(s) between the members 20 with each otherover time, as facilitated by relationship pair aggregation furtherdescribed below.

It is also recognised that the term member 20 can be assigned to asingle user and/or a group (e.g. two or more users) by theadministration system 26, such that any individual of the group can usethe group member 20 as a conduit to electronically interact with othergroup and/or individual members 20 via the network 11. For example, agroup member 20 can be a number of individual doctors working togetherin the same clinic and an individual member 20 can be a salesrepresentative connecting with and making appointments with the groupmember 20 as a customer of the sales representative (e.g. for sellingmedical supplies for the group individuals as a whole). It would be upto the individuals of the group member 20 to arrange amongst themselveswho would be meeting the sales representative at the arranged time/placeof the appointment, as the sales representative would not be concernedwith whom of the individuals of the group member 20 attend theappointment—just that at least one of the group individuals would beavailable and make able to make/relay decisions concerning buying ofmedical supplies.

The administration system 26 could consider the group member 20 as adistinct member 20 of the relationship environment 10, realizing thatany of the individuals of the group member 20 would have the samecapabilities/features/privileges 18 and can use the group member 20account 15 to interact 14 with other members 20. Alternatively, theadministration system 26 could consider the group member 20 as adistinct member 20 of the relationship environment 10, realizing thatcertain individuals of the group member 20 would have slightly differingdefined capabilities/features/privileges/restrictions 18 (e.g. definedindividuals when signed on as the group member 20 would only be able toview 14 appointments but not to confirm 14 them) when using the groupmember 20 account 15 to interact with other members 20 associated withthe relationship administration system 26.

One example application of the network 10 and associated administrationsystem 26 is for the healthcare industry, which can be characterized ashaving a particularly fragmented with a workforce—from physicians 20 tonurses 20 to practice administrators 20—that are extremely busy in theirday to day activities. Day to day work in industry can also be highlyirregular and unpredictable, and with so many different parts working inisolation there are limited opportunities for people to be exposed toone another. All of this makes it very difficult for industryprofessionals 20 to get in touch 14 with who they want when they needto, to stay in touch 14 with colleagues 20 and co-workers 20 withinand/or between different industries, and to coordinate productiveinteractions 14 with each other. Accordingly, the ability to coordinate14 meaningful and expected online relationships 12 between members 20,in particular the evolution of relationships between members 20 in aflexible and transparent manner is desirable, as further discussedbelow.

The relationship administration system 26 can be a web-basedservice/application, accessible by browser applications of the members20, and can provide a medium for the community of members 20 for people(in healthcare and other industries) to electronically (i.e. online)find 14 and connect 14 with peers and/or non-peers, electronicallycommunicate 14 and exchange ideas between members 20, and electronicallycoordinate interactions 14 (both online and in person, for example)between members 20; so that community members 20 can develop businessnetworks (for example in conjunction with different types offriendships), build knowledge, and/or engage in purposeful productiverelationships 12 outside of their immediate business environment. It isrecognised that the electronic communications/connections 14 between themembers 20 are conducted in the framework of the defined role pairs 12,for example, and the associated features/capabilities 18, as coordinatedby the administration system 26 further discussed below.

Customer-Vendor Example

Referring to FIGS. 1 and 4, an example of the role pair 12 is Vendors(role 12a) who use the system 26 to have access to customer relationshipmanagement tools 30 that let them, as companies or as individualrepresentatives with companies, reach out and connect 14 directly totarget their Customers (role 12b) for their proffered goods andservices. The management tools 30 provide the members 20 with differenttypes of connection 14 options with one another over the network 11. Thesystem 26 provides features that support the vendor 20 and the customer20 in building new relationships 12, in enhancing/evolving existingrelationships 12, and in enabling electronic communication,coordination, and value exchanges 14 between the assigned roles 12a,b ofthe role pair 12.

In economics, economic output can be divided into goods and services.When an economic activity yields a valuable or useful thing, it can beknown as production output of the totality of products (e.g. goods orservices) in an economy that the vendor 20 makes available 14 for use bythe customers 20. Products as goods can range from a simple safety pin,food, clothing, computer components to complex aircraft. Products asservices are the performance of any duties or work for another (e.g.helpful or professional activity) and can be used to define intangiblespecialized economic activities such as but not limited to: providingaccess to specific information; web services; transport; banking; legaladvice; accounting advice; management consultant advice; and medicalservices. The vendor 20 providing the products can be abusinessperson/individual engaged in wholesale/retail trade, anorganization, an administration, and/or a business that sells,administers, maintains, charges for or otherwise makes availableproduct(s) that are desirable by the customers 20. Accordingly, thevendor 20 can be one person, or an association of persons, for thepurpose of carrying on some enterprise or business; a corporation; afirm; etc. Further, it is recognized that the offered 14 (electronicallyand/or in person) products/services can be applied to vendor 20activities not related to specific product(s), for example activitiessuch as customer service, community activities, and/or sponsorships.These general activities of the vendor 20 are also considered as part ofthe definition of vendor 20 products.

It will be understood that for the purposes hereof, the customer 20 maybe any user (i.e. first hand product experience) of vendor 20 products(e.g. goods and/or services). For example, the customer 20 may be anindividual who purchases vendor 20 goods and/or services for personaluse, and not for resale or for use in the production of other goodsand/or services for resale. Or the customer 20 may be a businesspurchasing vendor 20 goods and/or services for use in its business,i.e., for resale or for use in the production of other goods and/orservices for resale. Further, it is recognized that customer 20 may notpurchase the goods and/or services. For example, the customer 20 mayhave acquire the goods and/or services pursuant to a free trial offeredby the vendor 20.

Any business or organization can be called an enterprise, whileconsumers are individuals or households that purchase and use goods andservices generated within the economy. It is recognized that bothenterprises and consumers can be included in the definition of customers20. For example, the definition of B2C (Business-to-Consumer) is used todefine the interaction between a business/vendor 20 (e.g. enterprise)that sells products or provides services to end-user consumers (e.g.customers 20). Further, for example, Business-to-Business (B2B) can beused to represent for relations between enterprises (e.g. between abusiness vendor 20 and a business customer 20), contrary to relationsbetween enterprises and other groups (e.g. customers, publicadministration). The term B2B can be used to define marketing activitiesas well as electronic communication relations between enterprises. Forexample, B2B-Marketing can be used to describe all products and servicesused by enterprises. B2B marketing can be considered more complex thanB2C marketing because on the buyer's side, there can be more than oneperson involved in a B2B sale/purchase, the buying center.

Accordingly, it is recognized that the customer 20 can be a privateindividual desiring information/purchase (e.g. B2C) of the vendor 20products or can be a person, or an association of persons, for thepurpose of carrying on some enterprise or business (e.g. a corporation,a firm, etc.) that desires information/purchase (e.g. B2B) of the vendor20 products. It is recognized that the customer 20 can communicate 14with the vendor 20 as a potential purchaser (i.e. window shopping) or asan intended purchaser of the vendor's 20 products, as desired.

Relationship Matrix 15

When two or more members 20 are engaged in one or more relationshippairs 12 (active and/or passive), these members 20 interact 14 with eachother on the administration system 26 (via the network 11) in accordancewith their relationship pair(s) 12 and their respective optional roles12a,b the members 20 have in those relationship pair(s) 12. It isrecognised that between any pair of members 20, a plurality of distincttypes of relationship pairings 12 can be assigned to them, whichfacilitates the evolution of their overall online relationship with oneanother. For example, any two members 20 can first start off with beingthe role of associates 12a,b in an associate based relationship pair 12(having associate features/capabilities 18a,b for coordination of thevarious connections/actions 14 enabled by the associate basedrelationship pair 12. At a later date, the two members 20 then add (e.g.aggregate) being the role of customer-vendor 12a,b in a customer-vendorbased relationship pair 12 having customer or vendor basedfeatures/capabilities 18a,b for coordination of the variousconnections/actions 14 enabled by the customer-vendor based relationshippair 12. In other words, the members 20 now have a general relationshipwith one another that is a combination of associate/customer 12a orassociate/vendor 12b with one another and therefore all of thefeatures/capabilities 18a,b assigned to each member 20 is a combinationof associate/customer 18a or associate/vendor 18b, as further describedbelow with respect to relationship banding and relationship aggregating.The relationship matrix 15 is used as a memory construct/database (e.g.table, chart, etc.) for defining/storing all of thefeatures/capabilities 18a,b, roles 12a,b, and/or all the possibleinteractions 14 between members 20 over the network 11.

It is also recognised that as an alternative embodiment the definedonline existing relationship 12 between a first member 20 and a secondmember 20 can be defined by a plurality of existing relationshipfeatures 18 for use in managing network interaction 14 on thecommunications network 11 between the first member 20 and the secondmember 20. The relationship features 18 are characteristic of therelationship 12, such that at least one of the correspondingrelationship features 18 of the relationship 12 is used to define aspermitted at least one of the network interaction 14 type, the networkinteraction content, or the network interaction format. It is recognisedthat the relationship features 18 can be between the first member 20 andthe second member 20 (i.e. each of the members 20 do not have a definedrelationship role 12a,b, in the relationship 12). Or, as furtherdiscussed above, it is recognised that a first portion of therelationship features 18a characterizes the first relationship role 12aand a second portion of the relationship features 18b characterizes thesecond relationship role 12b of the relationship pair 12, such that thefirst relationship role 12a and the second relationship role 12b arepart of the relationship defined as the relationship pair 12 between thefirst and second members 20. In other words, the aggregate relationshippair 12, described above by example only, can be administered by theadministration system 26 as a role-less relationship 12, such that therelationship features 18 are shared between the members 20 for managingtheir inter-member 20 interactions 14, or can be administered as a roled12a,b relationship pair 12, such that each of the roles 12a,b havecharacteristic role features 18a,b.

Referring to FIG. 8, any possible interaction 14 that can occur betweentwo members 20 can be defined and therefore enabled/disabled in therelationship matrix 15 via the respective features 18 and the actualimplementation of the interaction 14 is assessed (through reference tothe matrix 15) and either accepted or declined by the Relationship Gate150. The relationship matrix 15 is therefore available (locally orremotely over the network 11) to the Relationship Gate 150, to maintainan understanding of the roles 12a,b inside of the assigned relationshippairs 12 in affect (e.g. active and/or passive) at any point in timebetween members 20

The feature or capabilities 18a,b available between members 20 caninclude such as but not limited to: information visibility/sharing 14(via profiles, searches, contact records, etc.); notifications andupdates 14; communications 14; Events Coordination 14; Interactions 14Online and Coordination 14 of Interactions Offline; Preferences for thefeatures/capabilities 18a,b (i.e. limited member 20 specificcustomization of the general features/capabilities 18a,b available underthe role(s) 12a,b); and Relationship views 14.

Further, it is recognised that the matrix 15 is used by the relationshipgate 150 to determine whether or not an action 14 initiated by themember 20 with respect to another member 20 (e.g. send a meeting requestfor sales call) will be completed as an allowable RelationshipInteraction 14 (as defined by the features/capabilities 18, 1803, sharedor distributed in defined roles 12a,b), or whether the action 14 ishalted because it cannot occur (i.e. the desired action 14 is notcompatible with one or both of the feature/capability sets 18, 18a,b ofthe member(s) 20.

Further, it is recognised that the administration system 26 can providefeedback communication to the requesting member 20 if the action 14resulted in no Interaction (e.g. not allowed). Also, it is recognisedthat the administration system 26 can provide feedback communication tothe requesting member 20 if the action 14 resulted in Interaction (e.g.allowed). Also, it is recognised that the administration system 26 canprovide feedback communication/notification to the intended recipientmember 20 of the action 14 if it resulted in no Interaction (e.g. notallowed). Also, it is recognised that the administration system 26 canprovide feedback communication/notification to the intended recipientmember 20 of the action 14 if it resulted in Interaction (e.g. allowed).

Referring again to FIG. 8, thecapabilities/features/privileges/restrictions 18a,b (hereafter referableas features 18 for the sake of simplicity) are grouped asassociated/assigned to the respective individual relationship role 120,for example. For example, a first role type RT1 would have a set/groupof assigned features F1,F2,F3,F4,F5,etc. and a second role type RT2would have a set/group of assigned features F1,F3,F4,F6,F7,etc. It isrecognised that the sets/groups of assigned features 18 can have someindividual features 18 in common (e.g. overlapping sets/groups offeatures 18), however each set/group of features 18 as a whole is uniquein feature 18 content to the respective role type 12a that they areassigned. In this manner, the administration system 26 can facilitatethat a first role type RT1 has a unique first set of assigned features18 and therefore cannot be confused with a second role type RT2 having aunique second set of assigned features 18, such that the first andsecond set of features 18 are not identical. For example, the role type12a of a Colleague would have different set of features 18 than that ofa Vendor, otherwise a Colleague could be confused for a Vendor duringinteractions 14 over the network 11 as defined by the particular rolefeatures 18 set that is unique to the particular role type 12a.

It is also recognised that some features 18 can be superseded by otherfeatures 18, either in whole or in part (e.g. to take the place of suchas replace or to augment so as to make an already assigned feature 18greater/lesser in size, extent, or influence), during aggregation ofrelationship pairs 12 and their corresponding roles 12a,b and features18a,b, as further described below with respect to aggregate relationshippairs 6 (see FIG. 9).

Interactions/Connections/Communications 14

Referring again to FIG. 1, members 20 via the administration system 26can connect 14 with each other in ways that represent their real worldtrusted relationships, including nonmember 20 interactions. It isrecognized that the following discussed member 20 interactions 14 (asfacilitated/defined through the features/capabilities 18a,b that areshared between members of the relationship pair 12 and/or are associatedwith the role types 12a,b of the relationship pair 12) is for exemplarypurposes only, recognizing that nonmembers 20 can and will have at leastsome of the features/capabilities 18a,b that are appropriate to theirbase relationship profile 12a (e.g. public) recognized by the system 26.

Referring to FIGS. 1 and 6, the types of relationships (i.e. role 12a,bof the defined role pair 12) that member 1 (M1) is in with other members(Mn), and the administration system 26 connection relationships that aM1 has with a specific member (M2), will impact: the information M1 canenter 14 into the relationship data 15 about themselves; the informationM1 is able to share 14 about themselves, and who they're able to shareit with; the features/capabilities 18 a member 20 is able to use intheir defined role(s) 12a,b; the features/capabilities 18 M1 is able touse when interacting with Mn; the ability for M1 to join a Group; thetypes of requests/responses 14 that the member M1 can have over thenetwork 11; and/or the results 14 of any searches member M1 executes 14.Further, the relationships that a person may be dependent on factorssuch as: the role pair 12 assigned to the member 20; service package(s)purchased or otherwise acquired 18 by the member 20 as facilitated bythe system 26; and organization type and relationship of theorganization with the system 26. For example, in FIG. 6 member M1 (viatheir defined two role pairs 12 of customer-vendor andcolleague-colleague) can communicate 14 (as enabled/defined throughtheir various features/capabilities 18 as share and/or as assigned 180to respective roles 12a,b) with member M2 being both a fellow colleague12a and a respective customer 12a of member M1 (being a colleague 12aand vendor 12b). For example, member M1 and member M2 can interact 14with each other as colleagues 12a by sharing 14 their in-officecalendars (e.g. showing both personal and business activities) as wellas placing 14 and accepting 14 orders respectively for particular beautyproducts (i.e. member M1 is a part-time vendor of skin creams andcandles).

Member M1 can also communicate 14 with other vendors 12b (defined by thesystem 26) of the members Mn (for example other part-time vendors ofskin creams) to find out whether their customers may be interested intheir products (i.e. candles) and to make an introduction/referral 14 tothe member Mn customers 12a. This is an example where member M1 has anactive relationship role 12 of customer-vendor and colleague-colleaguewith member M2 and member M2 has passive relationship roles 12a,b ofvendor-vendor with other members Mn. It is recognised that the system 26s (and enforce via the relationship gate 150 see FIG. 7) the variouscapabilities/features 18b of the vendors 12b differently for theabove-described role pair customer-vendor 12 and vendor-vendor 12. Forexample, member M2 could offer 14 their products for sale to member M1with the ability to provide 14 order forms and invoicing. However,member M2 could not do these same interactions 14 with member Mn, rathermember M2 could only perform with member Mn initial contact 14 andrequest 14 introductions to the customers 12a of the member Mn. On theother hand, members M2 and Mn could decide to enter into customer-vendorrelationships 12 and then member M2 would gain the additional vendorfeatures/capabilities 18b commensurate with members Mn being theircustomer 12a.

It is recognised that the content (e.g. text, image, video, enclosures,message type (email, telephone, text message, etc.), message enclosures,content size/amount/length) and/or format (e.g. form of the content suchas colour, font style, message priority, etc.) of the interactions 14can be defined and their generation by the member 20 coordinated by theassociated features/capabilities 18 (e.g. of the role 12a,b) that themember 20 is using/operating under on the administration system 26 withselected (active and/or passive) other members 20. It is also recognisedthat the content and/or form of the interactions 14 can be defined usinga combination of different roles 120 and/or their associated features18a,b in view of aggregation of relationship pairs 12, further describedbelow.

In general, when a member (M1) initially connects 14 with another member(M2) via the system 26, M1 can choose the type or types of relationships(e.g. the role pair(s) 12) they are connecting to M2 in. Theserelationship role types can include defined role pairs 12 such as butnot limited to:

Business Relationship Communications Information Interactions ExchangeManagement Relationship Trust level 14 Sharing 14 14 Info 14Capabilities 14 Blocked None None None None None None Public (default)Minimum Minimum Minimum None None None Associate to Low Low Minimum NoneNone None Associate Colleague to High High High High Low Low ColleagueCustomer to Medium Medium Medium High High High Vendor/Vendor toCustomer Student to Medium Medium Medium High None Low Teacher/Teacherto Student Co-Worker to Medium Medium Medium Medium Medium Med Co-Worker

A number of interactions 14 are impacted by relationshipsfeatures/capabilities 18 of the defined role pair(s) 12 between themembers 20, including for example with respect to booking ofappointments/meetings and the contents/substance of the meetings:

-   -   Ability to input 14 available Time for appointments/meetings as        visible on their online profile 9;    -   Available Time Viewing 14 and Booking 14 for        appointments/meetings as visible on their online profile 9;    -   Sample requests 14 as visible on their online profile 9;    -   Product input and display 14 as visible on their online profile        9 or otherwise sent in communications 14 to their member of the        role pair 12;    -   Territory Management 14;    -   Call Management 14;    -   Call Mapping 14;    -   Auto Call Booking 14; and/or    -   Auto Rebooking 14 of Calls.        Example Interaction 14—Available Appointment Time

Referring to FIG. 1, the AVAILABLE TIME PROCESS allows members 20 whoare connected with each in a VENDOR (i.e. role 12b) and CUSTOMER (i.e.role 12a) relationship (i.e. role pair 12) to coordinate theirinteractions 14 so as to facilitate sales calls and meetings that aremore predictable and productive than the current prior art systems. Theprocess enables CUSTOMERS to identify 14 when they have AVAILABLE TIME(either MEETINGS or FLEX CALLS) for VENDORS to visit.

For MEETINGS, the CUSTOMER simply sets up 14 when he wants a VENDOR tocome (e.g. 10 to 10:15 am on Wednesday or 12:30 to 1:30 pm for lunch onThursday.) FLEX CALLS are periods of time that the CUSTOMER hasindicated they will accept a number of drop-in calls (e.g. between 1 pmand 3 pm on Fridays they would accept up to three FLEX CALLS.), asvisible on their online profile 9.

Only members 20 who are connected to a CUSTOMER as a VENDOR can see 14AVAILABLE MEETINGS and/or AVAILABLE FLEX CALLS as visible on theironline profile 9. VENDORS who want to BOOK 14 any OPEN MEETINGS or FLEXCALLS will do so on a first come first serve basis, and in accordancewith any preferences designated by the CUSTOMER as visible on theironline profile 9.

Only one VENDOR may be able to BOOK 14 a single MEETING. Once booked,the AVAILABLE MEETING is BOOKED and may be not visible to other VENDORSfor booking. (Note that a VENDOR or CUSTOMER can CANCEL the meeting,which could reopen the AVAILABLE MEETING to be booked by a differentVENDOR.

Multiple VENDORS can book 14 calls during an AVAILABLE FLEX CALL periodas visible on the CUSTOMER'S online profile 9. The number is limited bythe maximum specified by the CUSTOMER. A FLEX CALL that has been BOOKEDby a VENDOR is a period when they will be expected to drop in to see theCUSTOMER. The system 26 can divide the FLEX CALL period into a number ofset length (and overlapping, if needed) windows. VENDORS who book a FLEXCALL book a specific window, and this distributes the bookings andreduced situations where multiple VENDORS call on a CUSTOMER at the sametime.

The specific time within the AVAILABLE FLEX CALL TIME when the call isto be made is up to the VENDOR. This enables them to choose 14 a timethat works best with their schedule, but also provides flexibility tothe CUSTOMER who has no obligation to maintain an exact meeting time, asinput and then made visible on their online profile 9. Also, the actualdiscussion produced with a FLEX CALL has no set length, and will besomething that works for the VENDOR and the CUSTOMER.

Only system 26 USER TYPES that are in the CUSTOMER class of user typescan create 14 AVAILABLE TIME. Further, only system 26 Users who are aVENDOR CONTACT (i.e. part of the role pair(s) 12 defined between theVENDOR and CUSTOMERS) of these CUSTOMERs can view 14 the AVAILABLE TIMEas visible on the CUSTOMER online profile 9 to book it.

A VENDOR can view 14 a CUSTOMER's calendar on their online profile 9 tofind and BOOK any OPEN (not booked) AVAILABLE FLEX CALL WINDOWS. EachFLEX CALL WINDOW will have a start time and an end time (usually 60minutes apart.)

Only the VENDOR or a CUSTOMER can see and book 14 the AVAILABLE FLEXCALLS on the online profile 9 for the CUSTOMER, as defined and enabledvia their defined role pair 12. To other member types (such ascolleagues, co-workers, etc) the time where an AVAILABLE FLEX CALL canappear 14 on the member's online profile 9 to be BUSY time, whether thecall is BOOKED or OPEN. (This is because the CUSTOMER is saying thistime is booked for my VENDORS, and is therefore expected to be booked.).Accordingly, it is recognized that the online visible profile 9 of anyparticular member 20 to any other member 20 is influenced by the rolepair(s) 12 defined between the respective members 20.

Once a FLEX CALL WINDOW maximum booking number (BWmax) is reached, thatwindow is considered FULL and is not viewable by VENDORS other thanthose that have booked it. For both AVAILABLE MEETINGS and for AVAILABLEFLEX CALLS, the system 26 can permit the CUSTOMER to set PREFERENCES 18for the calls. These PREFERENCES 18 can take the form of:

-   -   Capability to set PREFERRED VENDORS, PREFERRED VENDOR        ORGANIZATIONS, PREFERRED PRODUCT INTERESTS, etc;    -   Frequency that any one VENDOR can BOOK an AVAILABLE MEETING;    -   Frequency that any one PREFERRED VENDOR can BOOK an AVAILABLE        MEETING;    -   Frequency that any one VENDOR can BOOK an FLEX CALL;    -   Frequency that any one PREFERRED VENDOR can BOOK an FLEX CALL;    -   Frequency that any one VENDOR ORGANIZATION can BOOK an AVAILABLE        MEETING;    -   Frequency that any one PREFERRED VENDOR ORGANIZATION can BOOK an        AVAILABLE MEETING;    -   Frequency that any one VENDOR ORGANIZATION can BOOK an FLEX        CALL;    -   Frequency that any one PREFERRED VENDOR ORGANIZATION can BOOK an        FLEX CALL;    -   Frequency that any one VENDOR that is discussing a specific        PRODUCT can call; and/or    -   Some AVAILABLE TIMES can be designated for specific PRODUCTS.        (This can be put in the notes, but the TRApp can also support        this by confirming the product type of the VENDOR.

The system 26 can also facilitate the capability to support multiCUSTOMER calls, and allowing multiple VENDORS to book 14 the same FLEXCALL PERIOD. This would be an event situation. CUSTOMERS can alsocustomize the FLEX CALLS to have FLEX CALL WINDOWS of any length. (e.g.60 minutes in length, except when the entire AVAILABLE FLEX CALLDURATION is 30 minutes when the window can also be only 30 minutes.

Relationships Defined Using Relationship Pairs 12

Referring to FIGS. 1 and 3, control and transparency of all connectionrelationships 12 in the networked environment 10 promotes member 20confidence in interactions 14. Members 20 know who they're connecting 14to, how they're connecting 14 to them, how they're being seen 14 byother members 20 they're connected to, and exactly what it means to beconnected 14 to another member 20 in a specific relationship pair 12.

Further, members 20 have control of their relationships 12, just likethey have in real life. It's not a one size fits all world and, inbusiness, people have different relationships 12, the administrationsystem 26 provides for this, for example through paired relationshiproles 12a,b, letting members 20 decide what relationship role 12a,b of apaired relationship 12 they want to have with another member 20. Thepaired relationship roles 12a,b (and optional directional relationships12, further described below) can provide that, when a member 20 engages14 in an online relationship 12 with another member 20, they know therole 12a,b they play in the relationship and the corresponding role12b,a the connected (of the relationship pair 12) member 20 plays. If apair of members 20 who are in only one customer-vendor relationship 12,then one of the members 20 must be the vendor role 12b and one must bethe customer role 12a. Example, in a colleague-colleague relationshippair 12 or in a customer-vendor relationship pair 12, it's clear to bothsides exactly what role 12a,b each member 20 is playing. For example, Ican't be someone's vendor 20, and not have them be my customer 20.

The relationship environment network 10 provides a social network to themembers 20, by enabling members 20 to connect to each other in ways thatrepresent their real world business relationships using definedrelationship pair(s) 12, including within the pairs 12 example roles12a,b such as but not limited to: as an associate; as a colleague; as aco-worker; as a customer; as a vendor; etc. Selected roles 12a,b arecompatible with other selected roles 120 and other selected roles 12a,bare not compatible with certain roles 12a,b, as further described below(for example, a role 12a of vendor may not be compatible with thefeatures/capabilities 18 of a role type 12b of colleague, while a role12a of vendor would be compatible with the features/capabilities 18 of arole type 12b of customer). It is recognised that each of the associatedroles 12a,b of the role pair 12 includes a pluralityfeatures/capabilities 18 that are defined by the administration system26, as further discussed below. Once connected via the system 26,members 20 users of the administration system 26 communicate, shareinformation, and/or coordinate interactions via communications 14 witheach other in accordance with their professional and/or personrelationship defined by their role(s) 12a,b with each other in the rolepair(s)/pairing(s) 12. It is recognized that the communications 14 canconsist of messages (e.g. SMS messages, texting, emails, phone calls,etc.) sent to one another, as well as viewing the online profiles 9(e.g. system 26 Web page showing the profile of the member 20 with username, interests, other member 20 connections, hobbies, etc.) of themembers 20.

Some relationships require both members 20 to be in the same role 12a,such as in a Colleague to Colleague relationship 12. Otherrelationships, such as Customer to Vendor relationships 12, require eachuser to have a different role 12a,b.

Referring to FIGS. 5a,b,c, in any relationship pairing 12, there can betwo relationship roles 12a,b that may be of the same or different roletypes. In FIG. 5a M1 is the colleague 12a and M2 is also the colleague12a, such that both members 20 M1 to M2 want to be Colleagues so bothusers must play the role of a Colleague 12a in this Colleague toColleague relationship 12. In FIG. 5b M1 is the customer 12a and M2 isthe vendor 12b, such that the two members 20 M1 and M2 want to be in aCustomer to Vendor relationship 12 where M1 plays the Customer role 12aand M2 plays the Vendor role 12b. In FIG. 5c M2 is the customer 12a andM2 is the vendor 12b for one relationship pair 12 and M1 is the vendor12b and M2 is the customer 12a for another relationship pair 12′ thatthey have, such that the same M1 and M2 members 20 can also have asecond Customer to Vendor relationship 12′ where M2 plays the Customerrole 12a and M1 plays the Vendor role 12b.

A relationship role 12a,b is the specific capacity a member 20 takeswhen acting in a system 26 supported relationship 12 with another member20 who has a specific counter/associated role 12a,b to that relationshippairing 12. It is recognised that the capabilities and features 18between two paired roles 12a,b may not be the same. For example, in aCustomer to Vendor relationship 12, one user must always be the role 12aof Customer 20 while the other user must always be the role 12b ofVendor 20, since the customer 20 is the one who asks questions about andpurchases items from the vendor 20, while the vendor 20 is the one thatprovides answers about products and facilitates sale of their products.The administration system 26 would define (via the matrix 15) and canassign of the allowable features 18a,b specific to the assigned role12a,b of the role pair 12. In other words, for example, the customer 20would not have (i.e. the matrix 15 would not enable these features 18bfor the customer role 12a) the vendor 12b type features 18b of offering14 products for sale and invoicing 14 for same over the network 11 withthe vendor 20 (since that is what a vendor 20 does), while at the sametime the vendor 20 would not have (i.e. the matrix 15 would not enablethese features 18a for the vendor roles 12b) the customer 12a typefeatures 18a of requesting 14 product information and paying 14 invoicesfor purchased products over the network 11 with the customer 20 (sincethat is what a customer 20 does). Accordingly, in this case, it is clearthat a particular member 20 can only be the customer role 12a withcorresponding features 18a when paired to the particular member 20 whois the corresponding vendor 12b role with corresponding features 18b,for the relationship pairing 12 of customer-vendor for the pairedmembers 20. It is also recognised that the features 18 of a selectedrelationship pair 12 can be shared between the members 20 of thatrelationship pair 12 in a role-less relationship pair 12.

For example, referring to FIG. 3, the system 26 provides a plurality ofpredefined role pairs 12 for selection by each of the members 20 (e.g. aplurality of different defined role pairs 12 having respective role 12aassociated with role 12b, such that each of the defined role pairs 12have assigned respective different feature/capability sets 18) that canbe assigned to any particular pair of the members 20. Therefore, each ofthe defined role pairs 12 has list of available features/capabilities 18that are associated with the particular role pair 12, for example role12a of role pair 12 has a list of features/capabilities 18a that iscompatible with the list of features/capabilities 18b of the role 12b ofthe role pair 12. It is recognized that the features/capabilities 18amay or may not be exactly the same as the features/capabilities 18b,i.e. may be different for each member 20 of the pair 12 such as forvendor-customers, student-teacher, etc. This is different from the casewhere the roles 12a are the same/equal such as for colleague tocolleague, friend to friend, member to member. In the case where thefeatures/capabilities 18a are the same, this could be where therelationship role pair 12 has two equal roles 12a (e.g. public topublic, friend to friend, colleague to colleague). In the case where thefeatures/capabilities 18a,b are not the same, this could be where therelationship role pair 12 has two associated dissimilar roles 12a,b(e.g. vendor to customer, student to teacher), however, it is recognizedthat the dissimilar features/capabilities 18a,b would be compatible withone another as defined by the role pair 12. It is also recognised thatthe features/capabilities 18a,b assigned to the roles 12a,b can bedirectional, such that there may be more assigned features/capabilities18a for the role 12 a as compared to the that the features/capabilities18b assigned to the role 12b of the role pair 12, as further describedbelow.

The features/capabilities 18 assigned to the roles 12 are reflected intype of connections 14 that can be initiated (and responded to) by themembers 20 in their relationship role(s) 12, An example of this is wherethe first member 20 having the role 12a could be a vendor and be able tosend vendor communications 14 listing products/services for sale, whilethe second member 20 having the paired role 12b of a customer would beable to receive 14, view 14, and respond 14 to the original vendorcommunications 14 (e.g. order to buy offered products/services), i.e.the members are in a Vendor-Customer role pair 12 relationship, asdefined in the system 26. It is recognized that the customer would notbe able to send vendor communications 14 to the vendor and the vendorwould not be able to place orders 14 to the customer, in this case,unless the members 20 had their relationship role data 15 defining botha Vendor-Customer role pair 12 and a Customer-Vendor role pair 12between them, such that each member is both a customer and a vendor withrespect to the other member 20 of their defined role pair(s) 12.

It is also recognized that for an active relationship 12 in theadministration system 26, both sides of the relationship pair 12 can becognizant of the assigned roles 12a,b of their other member 20 of theirmember pair 12, i.e. a vendor knows who their customer is and thecustomer knows who their vendor is and each is knowledgeable of thefeatures/capabilities 18 of the others role 12. In other words, a firstmember 20 cannot hide the fact from a second member 20 that the members20 have defined and dissimilar roles 12a,b that are compatible with oneanother (e.g. a customer of a vendor knows that they are identified inthe system 26 as the customer of the respective vendor and the vendor ofthe customer knows that they are identified in the system 26 as thevendor of the respective customer. It is also recognized that each ofthe members 20 can have a plurality of different roles 12a,b (ofrespective role pairs 12) with the same and/or different member(s) 20,such that each of the role pairs 12 (active and/or passive) have aninbound and an outbound role connection (i.e. directional roles 12a,b)to the other member 20 associated in the role pair 12.

For example, a first member 20 signs onto the system 26 and provides auser role/profile 12a (e.g. their profession, their specialty, theircountry, hobbies, and any other personal defining information). Thefirst member 20 may also set up with the system 26 certain defined roles12a,b that may or may not have accepted member pair relationships 12(e.g. the first member 20 can have a vendor role 12b with aconfirmed/accepted customer role 12a with a second member 20 thatdefines an active pair relationship 12, and/or the first member 20 canregister with the system 26 as a vendor 12b of a specificproduct/service and therefore have information 14 available to othermembers 20 as passive pair relationships 12). The system 26 can use theuser role definitions/parameters 18b as well as any defined roles 12b asset up by the first member 20 to provide for both active and passiveexchanges of information 14 between the first and second members 20. Forexample, in the case where the first member 10 is a general physicianand the second member 10 is a vendor for office medical supplies, thesystem 26 would use the user role/profile 12a of general physician andthe defined vendor role 12b to inform the first member 20 of the secondmember 20 as a potential supplier/vendor 12b of medical supplies and thesecond member 20 of the first member 20 as a potential customer 12a oftheir vendor role 12b. The mappings between potential role pairs 12(i.e. customer 12a with vendor 12b) as well as for accepted pairs 12 canbe monitored/maintained by the relationship matrix 15, as furtherdescribed below.

Therefore, providing members 20 control over the connection types(relationship role pair(s) 12) they have with other members 20 providesthey feel secure in that defined relationship 12. It is recognized thatthe relationship administration system 26 can have one or more defaultrole pairs 12 that can be assigned to nonmembers 20 trying tocommunicate 14 with one or more members/nonmembers 20 via the system 26.For example, each nonmember 20 can be recognized as having a public roleprofile 12a when trying to communicate via the system 26 with othermembers/nonmembers 20, who will also be associated with a public roleprofile 12a for facilitating communications 14 via the system 26 withthe non-member 20.

Example definitions of the various roles 12a,b available in theplurality of relationship pairs 12 is as follows. Associate is a personwho shares actively in anything as a business, enterprise, orundertaking as a partner or fellow worker. Colleague is a fellow memberof a profession, staff, or academic faculty. Friend is a person attachedto another by feelings of affection or personal regard and is a personwho gives assistance as a patron/supporter. Teacher is a person whoteaches or instructs, as a profession as an instructor. Coworker is afellow worker. Vendor is a person or agency that sellsproducts/services. Customer is a person who purchases goods or servicesfrom another as a buyer/patron. Student is a person formally engaged inlearning, especially one enrolled in a school or college as a pupil.Manager is a person who has control or direction of an institution,business, etc., or of a part, division, or phase of it. “Co” (e.g.co-manager, co-vender, etc.) is a fellow person with potentially thesame business/personal duties as another person. Delegate is a persondesignated to act for or represent another or others, for example as adeputy/representative. Patient is a person who is under medical care ortreatment. Provider is a person or thing that provides a service (e.g.healthcare related) to another person or thing.

Directional Relationship roles 12a,b

⋅It is recognised that the relationship pairings 12 can benon-directional and/or directional relationship roles 12a,b andassociated non-directional and/or directional relationshipfeatures/capabilities 180. For example, if two members 20 are in acustomer-vendor relationship pair 12, it is possible for those members20 to engage in another customer-vendor relationship pair 20. In thefirst relationship pair 12, member M1 may be the vendor and member M2may be the customer, while in the second relationship pair, member M1may be the customer, and member M2 may be the vendor. In this case, M1would only be enabled for the first relationship pair 12 for directionaloutgoing vendor interactions 14 (i.e. to customer) and incoming vendorinteractions 14 (e.g. from customer) in terms of the availablefeatures/capabilities 18b for a vendor 12b. As well, M1 would only beenabled for the second relationship pair 12 for directional outgoingcustomer interactions 14 (i.e. to vendor) and incoming customerinteractions 14 (e.g. from vendor) in terms of the availablefeatures/capabilities 18b for a customer 12a, for example. Further, M2would only be enabled for the first relationship pair 12 for directionaloutgoing customer interactions 14 (i.e. to vendor) and incoming customerinteractions 14 (e.g. from vendor) in terms of the availablefeatures/capabilities 18b for a customer 12a. As well, M2 would only beenabled for the second relationship pair 12 for directional outgoingvendor interactions 14 (i.e. to customer) and incoming vendorinteractions 14 (e.g. from customer) in terms of the availablefeatures/capabilities 18b for a vendor 12b, for example.

Another way to think about it is that relationship pairs can beoptionally directional, from one role 12a,b to the other. Therefore, thecapabilities and features 18a,b between two members 20 may not be thesame, because the direction of the relationship pair 12 matters. Forexample, in a Customer to Vendor relationship pair 12, one member 20must always be the Customer role 12a while the other member 20 mustalways be the Vendor role 12b. In this case, there is oneCustomer-Vendor relationship pair 12, but two separate RelationshipRoles 12a,b in that relationship pair 12: one Customer and one Vendor.This is talking to the fact that two people 20 can have tocustomer-vendor relationships 12, one in each direction, but that theycan have different features/capabilities 18a,b because the users 20 maycustomize how the accept/broadcast those features 18a,b.

Therefore, it is recognised that each relationship pair 12 providescapabilities 18a,b to the members 20. The relationship matrix 15 is incontact with the Relationship Gate 150, to maintain an understanding ofthe roles 12a,b and relationship pair(s) 12 in affect at any point intime between members 20.

Active/Passive Relationship Pairs 12

Each relationship between a pair of members 20 (e.g. member with member,member with non-member, or non-member with non-member) can consist ofone or more relationship pairs 12 (e.g. a first role 12a of the pair 12is assigned to one member 20 of the member pair and anassociated/complimentary second role 12b of the pair 12 is assigned tothe other member 20 of the member pair). It is recognized that there canbe both passive (one of the roles 12a,b of the pair 12 has not beenformally accepted by one of the members 20 of the member pair 12) andactive relationships in the system 26 (i.e. both of the roles 12a,b ofthe pair 12 have been recognized and accepted by each member 20 of themember pair 12—e.g. a first member 20 of the member pair 12 registerswith the administration system 26 in one of the roles 12a of the pair 12and the second member 20 of the member pair 12 formally accepts a roleinvitation 14 from the first member 20 for the other role 12b of thepair 12, as defined by the administration system 26).

Referring to FIGS. 1 and 7, there are two types of Relationship pairs12: Activated/Active Relationships 12 and Inherent/Passive Relationships12. Inherent relationships 12 can exist without the member 20 or members20 having to do anything specific to engage or activate the relationship12 between one or more members 20 accessible by the member via theadministration system 26 (e.g. via the relationship gate 150). Forexample, a relationship pair request 14 from a first member 20 does nothave to be received from and accepted by a second member 20, in order toestablish the inherent relationship pairing 12 and (and optionalassociate roles 12a,b) between two or more members 20. The relationshippair 12 is automatically put in place by the administration system 26when specific member 20 actions 14 occur that would enable the use oftheir inherent optional relationship role(s) 12a,b and assigned features18a,b or as their shared features 18 of the relationship pair 12. FIG. 7shows how the two inherent relationships 12 are always on.

Some inherent relationship pairs 12 include: a) Member (M) to Public (P)(which exists between any member 20 and any non-member 20; b) Member (M)to Member (M) (which exists between every member 20; and c) FamilyHealth Team mate (FHT) to Family Health Team (FHT) mate (which existsbetween all members 20 of a specific family health team;

Further, activated Relationship pairs 12 are started by one of themembers 20 who wants to engage in the selected relationship pair 12. Tostart an active relationship pair 12, one member 20 Initiates aHandshake (request 14 to enter into the relationship pair 12) to aselected other member 20 of the administration system 26. By executing14 the Handshake by the other member 20, the other member 20 activatesthe requested relationship pair 12 and therefore the requesting memberassumes the role 12a and the accepting member 20 assumes the role 12b ofthe relationship pair 12 with the associated features/capabilities 18a,bassociated with their roes 12a,b.

It is recognised that Most relationships can be Activated Relationshippairs 12, including a plurality of relationship pair 12 types such asbut not limited to: Friend (F) to Friend (F); Associate (As) toAssociate (As); Colleague (Co) to Colleague (Co); Coworker (Cw) toCoworker (Cw); Customer (Cu) to Vendor (V)/Vendor (V) to Customer (Cu);Student (St) to Teacher (Te)/Teacher (Te) to Student (St); Report (Re)to Manager (Mg)/Manager (Mg) to Report (Re); Delegate (Dte) to Delegator(Dtr)/Delegator (Dtr) to Delegate (Dte); CoVender to CoVender (CV);CoTeacher to CoTeacher (CT); CoManger to CoManager (CM); and Patient(Pat) to Provider (Pro)/Provider (Pro) to Patient (Pat), as shown inFIG. 7 as example roles 12a,b.

Therefore, when two members (assume M1 and M2) are in a relationshippair 12 with each other, there are Passive and/or Active relationshipinteractions 14 that may take place within the features/capabilities18a,b (optimally associated with the roles 12a,b) of the relationshippair 12 of the members M1,M2. For example, Active Interactions 14 can betriggered by an action 14 taken by member M1 or M2, such as activeinteractions but not limited to: Vendors request to ‘view availabletime’ and see the available flex calls of their Customers; Vendorsbooking available time for a call, since only vendors can book availabletime; and a member 20 changing their contact information (e.g. mobilephone number), such that this change is then shared with all of hisColleagues. In terms of passive interactions 14, these can happenwithout member M1 or M2 triggering the specific interaction. Examples ofpassive interactions 14 are such as but not limited to: the capabilityfor assuming M1 and M2 are colleagues; and a third member (M3) to seewho M1 is and that they are connected as colleagues to M2.

In an active exchange 14, there are connecting cooperative features18a,b between the members 20. Every feature 18a,b can have an entry wayand an exit way. In an active exchange 14, the relationship role 12a ofthe Initiator 20 must be such that the feature 18a can ‘Fit’ to allowthe initiation of the exchange 14 (e.g. create and send meetingrequest), and the relationship role 12b of the Receiver 20 must be suchthat the cooperative feature 18b will Fit the receiving end (e.g.receive and accept/decline meeting request) of the exchange 14.

It is recognised that whether or not a relationship pair 12 can exist,is available to start, and/or is maintained, etc, with respect to themembers 20 of the administration system 26 is coordinated theRelationship Gate 150, further described below.

The Relationship Gate 150

Referring to FIGS. 1 and 9, sending of interactions 14 (e.g. messages,emails, or viewing, or other network 11 enabled communications) does notalways require that the member 20 be in an active relationship pair 12,as in the case where the profile 9 of the member 20 is being viewed by anon-member 20.

The Relationship Gate 150 is used by the administration system 26 toprovide for allowed interactions 14 (e.g. in type, content and/orformat) between any members 20 over the network 11. The relationshipgate 150 has access to the relationship matrix 15 (see FIG. 8) thatstores all the available roles 12a,b and/or corresponding features 18a,bto a respective member 20 (e.g. for example in the case of a non-member24, the administration system 26 can assign a default role(s) 120 andcorresponding feature(s) 18a,b). The relationship gate 150 can be usedto restrict the transmission via the network 11 of any generatedinteractions 14 that do not match with the sender member 20 and/orreceiver member 20 assigned roles 12a,b and/or features 18a,b (shared ornot). Alternatively, or in addition to, the relationship gate 150 can beused to restrict the generation of any interactions 14 that do not matchwith the sender member 20 and/or receiver member 20 assigned roles 12a,band/or features 18a,b (shared or not).

For example, the member 20 may generate a vendor-based communication 14and then try to send the vendor-based communication 14 to a non-customerof the member 20, for which the relationship gate 150 would review theroles 12a,b and/or features 18a,b (shared or not) of the non-customermember 20, determine that the vendor-based communication 14 isinappropriate for the non-customer member 20 and then block or otherwiseinform (e.g. using a message that informs the role 12a,b incompatibilityof the non-customer member 20 with a suggestion of sending an invitationinstead to enter into a vendor-customer relationship role 12 with themember 20) the vendor member 20 of the inability to transmit thevendor-based communication 14. In this situation, the relationship gate150 could also modify and/or suggest (to the sending member 20)modifications to the vendor-based communication 14 to include a customerrole 12b invitation for sending to the non-customer member 20. In analternative embodiment, the relationship gate 150 could block the member20 from generating a message 14 that is not consistent (e.g. in terms ofmessage type, content, and/or format) with any of their current roles12a,b and/or features 18a,b (shared or not). For example, the member 20may want to generate a solicitation email for a new product line beingsold by the vendor member 20, however the product line and materialsassociated therewith (e.g. invoices, ordering forms, brochures, etc.)may not be enabled in the roles 12a,b and/or features 18a,b (shared ornot) of the member 20 in the matrix 15. The relationship gate 150 couldrespond to the member 20 to inform the member of the roles 12a,b and/orfeatures 18a,b lacking in their account 9, which needed in order to beable to generate the desired new product line message 14. For example,maybe the member's account 9 needs to be upgraded for multiple productline vendor status before the new product line can be a subject ofcommunications by the member 20.

Accordingly, the relationship gate 150 is used by the administrationsystem 26 to check whether any relationship pair 12, associated roles12a,b, and/or features 18a,b (shared or not) are in place, may beenabled, or are to be disabled, in order to facilitate the interactions14 desired by any of the members 20 with respect to other selectedmembers 20 of the system 26. If, at any time, two members 20 are in arelationship pair 12 where the relationship pair becomes unavailable oreither relationship role 12a,b becomes unavailable to one of the members20, then the relationship pair 12 can become cancelled from the matrix15. For example, one of the members 20 of the relationship pair 20 canleave the administration system 26, thereby cancelling their account 9.In this case, all of the relationship pairs 12 with this member 20 wouldbe cancelled and all of the corresponding relation roles 12a,b would bedeleted or otherwise treated as inactive in the matrix by theadministration system 26. It is recognised that the relationship gate150 could be used to update the matrix 15 for changes in roles 12a,b,and/or features 18a,b (shared or not), as desired.

Referring again to FIG. 9, or example, for Member 1 (M1) to be acustomer 12a and Member 2 (M2) to be a Vendor 12b: 1. M1 is able to be aCustomer 12a; 2. M2 is able to be a Vendor 12b; 3. M1 does not have anyRelationship pair 12 Restrictions 18a preventing them from initiating(or maintaining) a Relationship pair where they are the Customer 12a; 4.M2 does not have any Relationship Restrictions 18b preventing them frominitiating (or maintaining) a Relationship pair where they are theVendor 12b; 5. M1 does not have any Organization Restrictions 18apreventing them from being a Customer 12a; 6. M2 does not have anyOrganization Restrictions 18b preventing them from being a Vendor 12b;7. M1 and M2 do not (in a Customer to Vendor relationship) work 18a,b atthe same Organisation; 8. M1 is not in any relationship pairs 12 thatwould restrict or prevent them from initiating or maintaining a Customerto Vendor relationship pair and being the Customer 12a; 9. M2 is not inany relationship pairs 12 that would restrict or prevent them frominitiating or maintaining a Customer to Vendor relationship 12 and beingthe Vendor 12b, for example Relationship count limits 18a,b fall in heresince a member 20 cannot initiate a new relationship pair 12 of aspecific type if he or she has already used up all the availability ofthat relationship pair type 12).

Further to the above, it is recognised that features 18a,b of aparticular role 12a,b can contribute to revenue generation and enhancedrelationships possible with differentiated relationship pairs 12 havinguniquely characterizing role(s) 12a,b and associated features 18a,b (ascompared to other different role(s) 12a,b, in relationship pairs 12),such that the healthcare providers (or other industry specific members20) can comfortably connect with both their colleagues and theirvendors. Members 20 may have to pay to be able to be engage in specificrelationship pairs 12 and/or to gain desired features 18a,b (e.g.feature enhancements) for their selected roles 12a,b. For example, aservice package that a member 20 purchases from the administrationsystem 26 may restrict/enable 18a,b not only the types of relationshiproles 12a,b the member 20 can be, but the number of times 18a,b themember 20 can engage in a relationship pair 12 where they are playingthat role 120). For example, the administration system 26 may chargemarketing professionals 20 a marketing charge (e.g. $100/month) to beable to be 18a,b a Vendor in customer-vendor relationship pair 12.Further, the $100 package may only allow 18a,b the member 20 to havelimited number (e.g. 50) customer-vendor relationship pairs 12 wherethey are the Vendor 12a, while an increased value ($200/month) packagemay allow 18a,b more/additional/increased (e.g. 200) customer-vendorrelationship pairs 12, for example.

Handshake Example

Referring to FIGS. 1, 9, and 10, in Relationship Creation orHandshaking, e.g. for active relationship pairs 12, there is a Sender M1(or Initiator) and a Receiver M2. The Relationship Gate 150 decides,based on matrix data 15 for sender/receiver members 20, whether or not arelationship pair 12 is already in place, may be enabled, or is to bedisabled. There matrix defined factor(s) (e.g. matrix data 15 of therelationships including optional role 12a,b and/or feature 18a,b (sharedor not) for the members 20) that impact whether a member 20 can orcannot initiate a relationship and play a specific relationship 12 withanother member 20, such as but not limited to: 1. the Sender Mlcapability to be in the specific Relationship Role 12a; 2. the ReceiverM2 capability to be in the specific Relationship Role 12b; 3. if SenderM1 has any Relationship pair 12 Restrictions 18a and/or RelationshipEnhancements 18a (which for example can be provided via paid for servicepackages, organization affiliation, member affiliations, etc.); 4. ifReceiver M2 has any Relationship Restrictions 18 band/or RelationshipEnhancements 18b; 5. the Type of Organization the Sender M1 works with;6. the Type of Organization the Receiver M2 works with; 7. whether ornot the Sender M1 and Receiver M2 work at the same organization; 8.whether or not the Sender M1 shares a relationship pair 12 with anyother member (e.g. M3) that would restrict the sender M1 being able toenter into this relationship pair 12; and/or 9, whether or not theReceiver M2 shares a relationship pair 12 with any other member (e.g.M3) that would restrict the receiver M2 being able to enter into thisrelationship pair 12.

Referring again to FIG. 10, assume Member M1 wishes to initiate arelationship pair 12 with Member M2, such that they have not activatedany relationships previously. The Member to Public (P) is always active,but is superseded in this exchange by the Member to Member ‘Port’ 150a(such that the relationship gate 150 can have a number of ports 150aopen and/or operable for the members 20 depending upon their roles 12a,band/or features 18a,b. The Member to Member (M) Port is engaged betweenany two members 20. Assume the matrix 15 has data 15 that is compatiblewith the potential initiation invitations 14 for the potentialrelationship pairs 12 displayed in FIG. 10. In reviewing therelationship roles that sender M1 can initiate with M2, ⋅Associate (As)12a,b is available; Colleague (Co) 12a,b is available; Co Worker (CW)12a,b is unavailable with M2 because they are not at the sameorganisation 18a,b; Vendor (V) 12a,b is unavailable with anyone;Customer (Cu) 12a,b is available with M2 who can be a Vendor 12a,b;Teacher (Te) 12a,b is unavailable with anyone; Student (St) 12a,b isunavailable with M2 because M2 cannot be a Teacher to anyone: Manager(Ma) 12a,b is unavailable with anyone; and Report (Re) 12a,b isunavailable with M2 because M2 cannot be a Manager to anyone.

Relationship Banding

Referring to FIGS. 1 and 11, the features and capabilities 18 (shared ornot) associated with each relationship pairing 12 has a specific numberof defined features 18 as part of a minimum boundary/band feature set22,23 (e.g. combined) for each of the relationship pair 12 types (i.e.the features 18 in the minimum boundary/band feature set 22,23 mustremain enabled by the members 20 if they are to remain in the acceptedrelationship 12 selected/established between them. For example, therelationship pair 12 type “Associate to Associate” has a minimum bandfeature set 22 of F108 to F115 and the “Colleague to Colleague” has aminimum band feature set 23 of F100,F198,F199,F153 to F155. The members20 in the “Associate to Associate” relationship pair 12 know that eachof the members 20 has these minimum number of features 18 in theirminimum band feature set 22 for the respective relationship pair 12type, in order to maintain transparency and trust about the relationshippair 12 the members 20 created between each other (i.e. representativeof what it means to be in the relationship 12 characterized as associateto associate).

In the event that the relationship 12 between the members 20 evolves toinclude a second enriched relationship pair 12 (e.g. Colleague toColleague), which builds upon the first relationship pair 12 (e.g.associate to associate), the administration system 26 manages thatadditional features of a respective minimum boundary/band feature set 23for the second relationship pair 12 are added to the now aggregaterelationship 6, while providing that the first minimum boundary/bandfeature set 22 is maintained by the members 20 in the aggregaterelationship pair 6 (i.e. characterizing the combination of theassociate to associate and colleague to colleague relationships). Inthis manner, the members 20 in the aggregate relationship pair 6understand that the aggregate relationship pair 6 is characterized by atleast the features 18 contained in both minimum boundary/band featuresets 22,23.

Also in FIG. 9, it is shown that when in just a “member to member”public relationship pair 12, the minimum boundary/band feature set 25 isF001, F007, F011, F014, F015 and F031-F033, such that these features 18are all superseded (i.e. replaced, substituted) when the relationshippair 12 evolves to the associate to associate and the colleague tocolleague. In other words, the relationship features 18 for associate toassociate completely supersede those for the member to memberrelationship pair 12. It is recognised that the banded features 18 canbe optionally part of the individual roles 12a,b of the relationshippair 12, as desired.

Accordingly, relationships of the same name (e.g. relationship pair 12type), as defined by the administration system 26, always have minimumboundary/band feature sets 22, even when they are being used bydifferent members 20. This minimum number of features 18 enforced in therelationship pair 12 provides for that all members 20 understand what acolleague is, and what a vendor is, and what a customer is, for example.Though there can be some flexibility in relationship pairs 12, meaningthat members 20 can have some control as to how much information (e.g.enabled features 18) they have in a specific relationship pair 12 type,the minimum boundary/band feature sets 22 provide that no one member candeviate too far from those respective minimum features 18 of therelationship pair 12. For example, one member 20 as a colleague role12a,b cannot have the same features 18 and information sharingcapabilities 180 as another member 20 as a vendor role 12a,b, otherwiserelationship roles 12a,b would cease to have any meaning in the contextof different relationship pair 12 types having different features 18a,b.

One embodiment of the defined roles 12a,b provides for the banding ofthe features/capabilities 18a,b, such that progression from one lesserrole to the next greater role between any member pair 12 (e.g. fromfriend to colleague) provides for a minimum number of thefeatures/capabilities 18a,b of the lesser role 120 to be included asdefault features (e.g. part of the minimum boundary/band feature sets22) for the greater role 12a,b. This banding provides for members 20 totruly represent their accepted role 12a,b when interacting with theother members 20 of the member pair 12 using the assigned defined role12a,b. For example, a member 20 who has accepted another member 20 as afriend cannot simply turn off access 18 to the other member 20 fromtheir contact information (e.g. phone number, email address, homeaddress, etc.) that appropriately represents the friend role 12a,b. Itis understood that to be an accepted friend, some member information(and any other appropriate features/capabilities 18) cannot berestricted from the other member 20 of the member pair 12 on an adhocbasis. In other words, turning off or otherwise disabling of features 18from the minimum boundary/band feature set(s) 22 would cause the statedrelationship pair 6,12 to lose the understood (by the members 20) role12a,b characteristics inherent in the relationship pair 6,12 assigned tothe members 20. It is also understood that the evolution of the minimumboundary/band feature sets 22 for aggregate relationship pairs 6 can behierarchical in assignment.

Referring again to FIG. 8, thecapabilities/features/privileges/restrictions 18 are grouped asassociated/assigned to the respective individual relationship role12a,b. It is recognised that the sets/groups 22,23 of assigned features18 can have some individual features 18 in common (e.g. overlappingsets/groups 22,23 of features 18), however each set/group 22,23 offeatures 18 as a whole is unique in feature 18 content to the respectiverole type 12a that they are assigned. In this manner, the administrationsystem 26 can facilitate that a role 12 type has a unique first set 22of assigned features 18 and therefore cannot be confused with a secondrole 12 type having a unique second set 23 of assigned features 18, suchthat the first 22 and second set 22 of features 18 are not identical.For example, the role type 12a of a Colleague would have different set23 of features 18 than that of an Associate, as would the aggregate role8 of associate+colleague (see FIG. 9) would have an aggregate set 22+23of features 18

It is also recognised that some features 18 can be superseded by otherfeatures 18, either in whole or in part (e.g. to take the place of suchas replace or to augment so as to make an already assigned feature 18greater/lesser in size, extent, or influence), during aggregation ofrelationship pairs 12 and their corresponding roles 12a,b and featuressets 22,23, as further described below with respect to aggregaterelationship pairs 6 (see FIG. 9).

As an alternative embodiment to relationships 12 and banding, it is alsorecognised that the defined online existing relationship 12 between afirst member 20 and a second member 20 can be defined by a plurality ofexisting relationship features 18 for use in managing networkinteraction 14 on the communications network 11 between the first member20 and the second member 20. The relationship features 18 arecharacteristic of the relationship 12, such that at least one of thecorresponding relationship features 18 of the relationship 12 is used todefine as permitted at least one of the network interaction 14 type, thenetwork interaction content, or the network interaction format. It isrecognised that the relationship features 18 can be between the firstmember 20 and the second member 20 (i.e. each of the members 20 do nothave a defined relationship role 12a,b, in the relationship 12). Or, asfurther discussed above, it is recognised that a first portion of therelationship features 18a characterizes the first relationship role 12aand a second portion of the relationship features 18b characterizes thesecond relationship role 12b, such that the first relationship role 12aand the second relationship role 12b are part of the relationshipdefined as the relationship pair 12 between the first and second members20. In other words, the aggregate relationship pair 12, described aboveby example only, can be administered by the administration system 26 asa role less relationship 12, such that the relationship features 18 areshared between the members 20 for managing their inter-member 20interactions 14.

Relationship Aggregation

Referring to FIGS. 1 and 12a,b, the relationship pairs 12 and theassociated roles 12a that are assigned to a respective member 20 by theadministration system 26 can change over time, as the onlinerelationship the member 20 has with other members 20 alsogrows/changes/evolves over time. Flexibility in relationship 12evolution management is facilitated by the ability of the administrationsystem 26 to aggregate relationship pairs 12. Members 20 may not alwayshave the same relationship with each other over time, and therefore theadministration system 26 provides the environment for memberrelationships to alter, grow, and/or diminish in their relationshipcharacteristics (e.g. relationship roles 12a,b and associated features18a,b and interaction 14 abilities.

Therefore, relationships 12 and optional relationship roles 12a,b canchange, as coordinated by the administration system 26, and in changingsome relationship features 18 and/or roles 12a,b can supersede (eitherin whole or in part) one another. For example, two members 20 could bepaired 12 as Associates but then become closer and decide to becomepaired 12 as Colleagues. In becoming colleagues, their associaterelationship 12 could be superseded because all of the features andcapabilities 18 of the Associate relationship 12 could be within theColleague relationship 12.

Further, individual relationships 12 and the corresponding relationshiproles 12a,b need to be able to grow, in order to provide for desiredricher (e.g. additional feature 18 supported) interaction(s) 14 betweenthe members 20 of the evolving/growing relationship 12. One mechanismprovided by the administration system 26 to support the evolution ofrelationships is the coordination of aggregate relationship pairs 6 thatcan involve multiple relationship sub-pairs 12. For example, two members20 could be in a colleague-colleague relationship pair 12, but also wantto engage in a customer-vendor relationship pair 12 as well as astudent-vendor relationship pair 12. The administration system 26facilitates the management of the associated roles 12a,b as an aggregaterole 8 and the associated features set 18 as an aggregate feature set 4by enabling individual relationship pairs 12 that have differentfeatures and capabilities 18 to aggregate.

An example of relationship evolution between members 20 is Joe Smith M1goes to University to be a Doctor. While at University, the teachershave decided to use a valuable medical industry social CRMnetwork—administration system 26—to work with their students 20. One ofJoe's M1 professors is Dr. Jones M2. Joe M1 connects with Dr. Jones M2on the administration system 26 in a Student-Teacher relationship pairRP-ST. Joe M1 gels his residency at Toronto General, as shown in FIG.12a. He leaves university to start his new full time position. Inleaving school, the system 26 asks him to confirm that his relationshippair RP-ST (as Student to Teacher) be cancelled or changed, showndeleted by stippled lines for R-T,F-T and R-S,F-S in FIG. 12b.

Next, the final result of relationship evolution is shown in FIG. 12b,where first Joe M1 requests, via a handshake 14, that Dr. Jones 20accept new relationship pair RP-AA—an Associate to Associate. Joe M1 isnow a physician at Toronto General, and he meets Dr. Jones M2 one day inthe hall as Dr. Jones M2 is now performing many consultations at thehospital. They M1,M2 end up being able to become closer, and are nowcolleagues. They change their administration system 26 via interactions14 with one another to reflect this, i.e. to add a colleague tocolleague pair RP-CC. Joe M1 decides he is no longer interested inworking with the providers, and interviews with AstraZeneca to work withtheir medical department. They accept that, and he moves to AZ. He keepshis Colleague to Colleague relationship pair RP-CC with Dr. Jones M2,but now also requests 14 that Dr. Jones M2 accept him as a Vendor for AVproducts, thus further evolving their relationship in the administrationsystem 26 to add a vendor-customer relationship pair RP-VCust.

In view of the above example, it is recognised that the individualrelationship pairs RP-AA, RP-VCust, RP-CC are aggregated to define thecorresponding aggregate relationship pair 6 (an aggregation of thedifferent individual relationship pairs 12) between the members M1,M2.Further, it is recognised that the corresponding aggregate role 8 is anaggregated combination of the individually defined roles 12a,b (e.g.role R-A, R-A, R-V, R-Cust, R-C, R-C) of each of the individualrelationship pairs RP-AA, RP-VC, RP-CC, and the corresponding aggregatefeatures/capabilities 4 is an aggregated combination of the individuallydefined features/capabilities 180 (e.g. features/capabilities C-A,C-A,C-V,C-Cust, C-C, C-C) of each of the individual relationship roles12a,b. In other words, the administration system 26 provides for definedinteractions 14 between any paired members 20 based on their aggregatefeatures/capabilities 4 as defined via their corresponding aggregaterole 8. For example, Joe M1 interacts 14 with Dr. Jones M2 in theiraggregate relationship pair 6 using any of the aggregatefeatures/capabilities 18. In view of the defined interactions 14facilitated by the system 26 via the relationship gate 150 (see FIG. 7),either of the members M1,M2 can recognise what individual role 12a,b(and/or combined role 12a,b) available in the aggregate role 8 that themember M1,M2 is using during the interactions 14, as any of theaggregate features/capabilities 4 can retain and/or combine theirindividual defined characteristic features/capabilities 18characteristics represented in the interactions 14.

Further, in view of the above, it is recognised that certain feature(s)18 can be such as but not limited to: unique (e.g. only provided) by aparticular role 12a,b and therefore become additions/deletions to/fromthe existing/aggregate features 4 when the roles 12a,b are aggregated(i.e. when a new role 12a,b is added to existing role(s) 12a,b oraggregate role 8 and/or existing role(s) 12a,b is/are deleted/removedfrom the existing aggregate role 8 (or existing single role 12a,b); canoverlap (e.g. be in common) between two or more roles 12a,b andtherefore become redundant aggregate feature(s) 4 when the roles 12a,bare aggregated; can be conflicting with other existing features 18 ofthe set of aggregate features 4 and therefore the new and/or existingfeatures 18 can be disabled/deleted from the aggregate features 4 whenthe roles 12a,b are aggregated; can supersede or be superseded (e.g.either the new or existing feature is a preferred feature 18) overexisting/new feature(s) 18 in the aggregate features 4 and therefore thenon-preferred features new and/or existing features 18 can bedisabled/deleted from the aggregate features 4; or a combinationthereof.

Further, it is recognised that the process of aggregation performed bythe administration system 26 for example, to result in the aggregaterelationship pair 6 and associated optional aggregate role 8 andassigned aggregate features 4, can be defined by such as but not limitedto: the combining of a selected (e.g. by the member 20 and/or requested14 by another member 20) new optional role 12a,b to an existingrelationship role 12a,b or to two or more existing roles 12a,b (e.g. toan existing aggregate role 8) of a relationship pair 12,6; the deletingof a selected role 12a,b from two or more existing roles 12a,b (e.g. toan existing aggregate role 8) of a relationship pair 6; and/or theamendment of an existing relationship role 12a,b or of at least one oftwo or more existing roles 12a,b (e.g. to an existing aggregate role 8)of a relationship pair 12,6 through the combining with selected newrole(s) 12a,b and/or an existing aggregated role 8.

It is recognised that the content (e.g. text, image, video, enclosures,message type (email, telephone, text message, etc.), message enclosures,content size/amount/length) and/or format (e.g. form of the content suchas colour, font style, message priority, etc.) of the interactions 14can be defined by and their generation facilitated by the associatedfeatures/capabilities 18a,b (e.g. of the optional role 12a,b or asshared by the members 20 of the pair 12) that the member 20 isusing/operating under in the administration system 26 with selected(active and/or passive) other members 20. It is also recognised that thecontent and/or form of the interactions 14 can be defined using acombination of different roles 12a,b and their associated features 18a,bin view of aggregation of relationship pairs 12. Therefore, theaggregate features 4 of the aggregate role 8 can cooperate togetherand/or separately, as selected by the respective member 20 to generate14 and/or to respond/reply 14 to communications over the network 14between member(s) 20 that are part of the member aggregate relationshippair 4 governed by the aggregate roles 8a,b assigned to the members 20of the aggregate relationship pair 4.

For example, when Joe M1 asks 14 Dr. Jones M2 to dinner, thecharacteristics (e.g. text, image content and/or format) of theinteraction 14 can be defined by the particular features/capabilities 18Joe M1 is using from his aggregate role 8 of the aggregate relationshippair 6 with Dr. Jones M2. For instance, Joe M1 can send an email 14 toDr. Jones M2 requesting a meeting at a corresponding time and place.Based on the use of certain individual role(s) 12a,b in the aggregaterole 8, by Joe M1, when generating the email 14, Joe M1 can affect theperceived tone (e.g. business, personal, or a combination thereof) ofthe email 14 by selecting certain features/capabilities 18a,b associatedwith selected roles 12a,b of his aggregated role 8 with Dr. Jones M2.For example, Joe M1 can select in communication with interaction 14building capabilities of the administration system 26 (e.g. via browseras a thin client of the administration system 26 as a Web service),and/or via an administration system module/application 27 installed onhis device 101, see FIG. 2, (e.g. as a thick client of theadministration system 26), the particular roles R-V,R-C and thereforehave available all of the content/format features C-V,C-C to generatethe email 14. In this case, Joe M1 can include in the email 14 vendordetails (via the selected individual capabilities C-V of the selectedindividual role R-V) of his products with marketing and/or ordermaterials (as email enclosures) and can also have the email 14 typeformatted (via the selected individual capabilities C-C of the selectedindividual role R-C in the role 8) to be perceived as a colleaguemeeting invitation. This would provide for Dr. Jones M2 to understandthat the proposed meeting will be a combination of business and personalinteraction between them, e.g. a soft sell environment with potentialfor extended interaction in the colleague context. On the contrary, JoeM1 can include in the email 14 only vendor details (via the selectedindividual capabilities C-V of the selected individual role R-V in therole 8) of his products with marketing and/or order materials (as emailenclosures) with corresponding formatting (via the selected individualcapabilities C-C of the selected individual role R-C in the role 8).This would provide for Dr. Jones M2 to understand that the proposedmeeting will be a strictly business interaction between them, e.g. aharder sell environment with little/no time for extended interaction inother role 12a,b contexts of the aggregate role 8 of the aggregaterelationship 6. It is recognised that both Dr. Jones M2 and Joe M1 arecognizant of the extents (i.e. list of possible individual roles 12a,band associated individual features 18a,b) of their aggregaterelationship pair 6.

As well, further to the above example, Dr. Jones M2 can also include inhis response communication 14 (e.g. email and/or telephone call) theappropriate type of response as dictated by the individual role(s) 12a,bused to generate the original email 14. For example, in the strictbusiness sense, the relationship gate 150 may disallow returncommunication 14 (to the email 14) in the form of a telephone call, asthis would not be available as a feature/capability 18 in a customerrole R-Cust in response to received product solicitation emails 14 (i.e.Joe M1 only used his role R-V to generate the email 14). On the otherhand, in the event where Joe M1 used his role R-V to generate the email14 along with his role R-C as part of his aggregate role 8, therelationship gate 150 could allow Dr. Jones M2 to informally reply 14 tothe original email 14 using a telephone call 14 as part of the featuresC-C afforded by Dr. Jones M2 role R-C of his respective aggregate role8.

In view of FIGS. 1 and 12a,b and the above evolution example, it isrecognised that aggregation of relationship pair 12 types (i.e. anymember 20 assuming the roles 12a and associated features/capabilities18a of a plurality of relationship pair types 12) can be used torepresent electronically the definition of the Aggregate relationshiprole 8 for a member 20, representing the composite/aggregation ofindividually defined roles 12a,b that a member 20 has between two ormore other members 20 of the administration system 26. Accordingly, theAggregate relationship role 8 provides for any member 20 to evolve theiraggregated relationship pairs 12 over time as an assembly/combination ofseparate parts/portions of features/capabilities 18a defined for anumber of respective different defined relationship roles 12a of anumber of different relationship pair 12 types. It is recognised thatthe roles 12a,b as part of the aggregate relationship role 8 can affectthe growth and/or shrinkage in size and/or effect of the capabilities,features, and restrictions 18 associated with each overall aggregaterelationship 12 (i.e. a combination/aggregation of differentrelationship pairs 12) between pairs of members 20. Therefore, theprovision and coordination of aggregate relationship pairs 6 by theadministration system 26 between pairs of members 20 can provide forincremental increase/decrease in the size and/or effect of theassociated roles 12a,b, and corresponding features/capabilities 18a,b asa collection from separate/individual defined roles 12a,b andcorresponding features/capabilities 18a,b aggregated within theaggregate relationship pair 6.

As an alternative embodiment, it is also recognised that the definedonline existing relationship 12 between a first member 20 and a secondmember 20 can be defined by a plurality of existing relationshipfeatures 18 for use in managing network interaction 14 on thecommunications network 11 between the first member 20 and the secondmember 20. The relationship features 18 are characteristic of therelationship 12, such that at least one of the correspondingrelationship features 18 of the relationship 12 is used to define aspermitted at least one of the network interaction 14 type, the networkinteraction content, or the network interaction format. It is recognisedthat the relationship features 18 can be between the first member 20 andthe second member 20 (i.e. each of the members 20 do not have a definedrelationship role 12a,b, in the relationship 12). Or, as furtherdiscussed above, it is recognised that a first portion of therelationship features 18a characterizes the first relationship role 12aand a second portion of the relationship features 18b characterizes thesecond relationship role 12b, such that the first relationship role 12aand the second relationship role 12b are part of the relationshipdefined as the relationship pair 12 between the first and second members20. In other words, the aggregate relationship pair 12, described aboveby example only, can be administered by the administration system 26 asa role less relationship 12, such that the relationship features 18 areshared between the members 20 for managing their inter-member 20interactions 14.

Relationship Engine of the Administration System 26

Referring to FIGS. 1 and 13, shown is a relationship network environment10 for facilitating communications 14 between members and nonmembers20,24 (e.g. using a computing device 101—see FIG. 2) via therelationship administration system 26. Relationship data 15 ismaintained by a relationship engine 100 of the system 26 for one or morepairs 12 defined for a pair of the members/nonmembers 20,24. The mode,format, and/or information content of the communications 14 between themembers/nonmembers 20,24 may be monitored or otherwise structured by therelationship administration system 26 in view of the particularfeatures/capabilities defined in the relationship data 15 of the pair(s)12 defined for the member pair. The relationship engine 100 provides forinitializing, maintaining, and modifying the defined pair(s) 12associated with a selected pair of the members 20, as well as managingthe interactions 14 based on the data 15.

For example, evolving a defined online existing relationship 12 betweena first member 20 and a second member 20 is performed by the engine 100,such that the online existing relationship 12 is defined by a pluralityof existing relationship features 18 for use in managing networkinteraction 14 on a communications network II between the first member20 and the second member 20. The engine 100 facilitates receiving by aselection module 162 a new online relationship 12 (for example submittedby one of the members 20) having new relationship features 18, such thatthe new features 18 are different from the existing relationshipfeatures 18. The new relationship features 18 are characteristic of thenew relationship 12. The engine 100 aggregates the existing relationshipfeatures 18 (and optionally for the aggregate role 8 by aggregating thenew and existing roles 12a,b) and the new relationship features 18 by anaggregation module 160 as aggregate relationship features 4, which are acombination of the existing relationship features 18 and the newrelationship features 18, in order to define the aggregate relationship6. The engine 100 stores the aggregate relationship features 4 in astorage 210 of the administration system 26 as relationship data 15representing the aggregate relationship 6 defined by the relationshipfeatures 4 for example by the aggregator module 160.

A further optional operation is by clone a banding module 164 fordefining a minimum number (e.g. sets 22,23) of aggregate features 4 ofthe aggregate relationship 6 that must be maintained, as discussedabove. A further optional operation is by a role module 166 for definingthe aggregate role 8a,b for each of the members 20 of the aggregaterelationship 6 that is confirmed by the member (s) 20. It is alsorecognised that the role module 166 can be used to define anydirectional and inherent/passive nature of the roles 8a,b.

Further, the engine 100 has the relationship gate module 150 configuredfor accessing the relationship data 15 in order to determine whether aselected network interaction 14 from one of the members 20 is permittedin view of at least one of the corresponding aggregate relationshipfeatures 4 of the aggregate relationship 6. The relationship gate module150 also facilitates the selected network interaction 14 between themembers 20 when determined as permitted, such that the at least one ofthe corresponding aggregate relationship features 4 of the aggregaterelationship 6 is used to define as permitted at least one of thenetwork interaction 14 type, the network interaction content, or thenetwork interaction format.

It is also recognized that multimember pairings 12 could be implementedby the system 26, for example where each of a plurality of members ispaired to a respective member (e.g. a many to one pairing) or arespective member is paired to a plurality of members (e.g. a one tomany pairing). This type of pairing provides for the setup of groupsettings, such as a plurality of customers that are serviced by avendor, a plurality of vendors that are selected to service a particularcustomer, a manager that has a number of employees, etc. In this manner,communications 14 between the members in group settings can be performedin parallel, such that an offer from one vendor can be communicated 14simultaneously to the each of the plurality of customers associated withthe vendor, via the respective defined vendor customer role pairs 12between the vendor and each of the customers of the plurality ofcustomers of the system 26. Also, in the case of multiple vendors for aparticular customer, each of the vendors could be made aware (via thesystem 26) of an offer proposed by one of the vendors to the customer(e.g. in a open bid process in a Request for Proposal situation).Further, it is also recognized that a many to many member group can beset up, such as in the case of a group of friends, a group ofcolleagues, etc. In this manner, communications 14 sent to one of themembers of the group would be communicated to each of the other membersof the group.

However, in each of the above multimember pairing examples, there canexists defined role 12a,b between any two member pair of the pluralityof members 20, i.e. in the colleague group example, each of the membersof the group would have a colleague-colleague defined role 12a,b witheach of the other members of the group. A further embodiment is wherethere is a relationship defined as a three (or more) person “pairing”such that there are three or more roles 12a,b,c, with associatedfeatures/capabilities 18a,b,c to define the complete set of interactions14 between the multi-person “pairing” 12. In this manner, each of themembers of the multi-person pairing (also know as a member set) has asubset of the total features/capabilities 18a,b,c (somefeatures/capabilities 18a,b,c can be overlapping between the members ofthe member set. For example, a relationship member set of a teacher, atutor, and a student can be implemented in the system 26, such that eachmember of the member set is connected to each other as defined by theindividual relationship roles defined in their relationship data 15. Forexample, the teacher, tutor, student combination could contain theindividual pairings 12 of student-teacher, teacher-student,student-tutor, tutor-student, teacher-tutor, and tutor-teacher, suchthat each of the roles 12a,b,c of the member set pairing 12 would havethe associated features/capabilities 18a,b,c. For example, the tutor andthe teacher could share 14 exam results and other evaluationcriteria/comments of the student (which are blocked 14 from view fromthe student), the tutor could receive and respond 14 to laboratoryquestions from the student, however these questions would not becommunicated 14 to the teacher until first reviewed/commented on by thetutor, etc.

In the manner as discussed above by example, the format, content, mode,and other features/capabilities of the communications 14 (includinginformation visible on the Web page/profile page 11 of the memberaccount) between members is monitored and/or otherwisemaintained/structured by the system 26.

The following is a list, for example only, of the configuration of therelationship data 15 between any pair of members of the system 26:

-   -   Users choose relationships (i.e. pair(s) 12) to have with        another users;    -   Some relationships are aggregated/combined/Some are        hierarchical;    -   Relationships can be removed/downgraded/upgraded;    -   A relationship connection can use two one way connections 120,        e.g. the vendor has a vendor customer connection 12a with the        customer and the customer has a customer—vendor connection 12b        with the vendor). Therefore, the user offering any relationship        uses a complimentary relationship in reverse. So to be in a        relationship, the other user accepts the complimentary        relationship to have back. To accommodate the creation of ‘two        relationships’, each user adopts a relationship role 12a,b in        any two way relationship 12 (also would apply in member sets        having more than two members);    -   Relationships are impacted by time, and can require        checks/changes/upgrades/downgrades/etc;    -   Events may trigger relationship checks/changes;    -   User roles may impact relationship;    -   User relationships with other users/organizations may impact        potential for relationships with another user;    -   User may alter, within limits, relationship permissions by        customizing the available customizable features/capabilities of        the defined role pairing 12. (There can be minimum permissions        and maximum permissions associated with each relationship, so as        to maintain a band of commonality with each relationship so        users become used to what it means to be involved in that        relationship.);    -   Capability to start/maintain a relationship may be impacted by:        -   User role of Initiator        -   User role of Receiver        -   Service package of Initiator        -   Service package or Receiver        -   Organization Environment of Initiator        -   Organization Environment of Receiver;    -   Connections or “pipes” (e.g. one-way connection of the two way        relationship) may be used to transfer information/features;    -   Some “pipes” may be active. Some may be passive; and    -   Some relationship pipes are always in place, depending on the        user role. (For example, a base user always has ‘Public’ pipes        in place displaying a limited amount of information to the        public).        Operation of the System 26

Referring to FIGS. 1, 12b, 13, and 14, a method 300 for evolving adefined online existing relationship 12 between a first member 20 and asecond member 20 is provided, such that the online existing relationship12 is defined by a plurality of existing relationship features 18 foruse in managing network interaction 14 on a communications network 11between the first member 20 and the second member 20. The method 300comprises the steps of: step 302 receiving by the selection module 162 anew online relationship 12 having new relationship features 18 such thatthe new features 18 are different from the existing relationshipfeatures 18, the new relationship features 18 being characteristic ofthe new relationship 12; step 304 aggregating the existing relationshipfeatures 18 (and optionally for the aggregate role 8) and the newrelationship features 18 by the aggregation module 160 as aggregaterelationship features 4 as a combination of the existing relationshipfeatures 18 and the new relationship features 18 in order to define anaggregate relationship 6; step 306 storing the aggregate relationshipfeatures 4 in a storage 210 of the administration system 26 asrelationship data 15 representing the aggregate relationship 6 definedby the relationship features 4; and step 308 of accessing therelationship data 15 by the relationship gate 150 in order to determinewhether a selected network interaction 14 from one of the members 20 ispermitted in view of at least one of the corresponding aggregaterelationship features 4 of the aggregate relationship 6 and facilitatingthe selected network interaction 14 between the members 20 whendetermined as permitted, such that the at least one of the correspondingaggregate relationship features 4 of the aggregate relationship 6 isused to define as permitted at least one of the network interaction 14type, the network interaction content, or the network interactionformat.

A further optional step 310 is by a banding module 164 for defining aminimum number of features 4 of the relationship 6 that must bemaintained. A further optional step 312 is by a role module 166 fordefining the aggregate role 8a,b for each of the members 20 of therelationship 6 that must be confirmed by the member (s) 20. It is alsorecognised that the role module 166 can be used to define anydirectional and inherent/passive nature of the roles 8a,b.

Computing Devices 101

Referring to FIGS. 1 and 2, each of the above-described members 20 andadministration systems 26 can be implemented on one or more respectivecomputing device(s) 101. The devices 101 in general can include anetwork connection interface 200, such as a network interface card or amodem, coupled via connection 218 to a device infrastructure 204. Theconnection interface 200 is connectable during operation of the devices101 to the network 11 (e.g. an intranet and/or an extranet such as theInternet), which enables the devices 101 to communicate with each otheras appropriate. The network 11 supports the communication 14 of the databetween the administration system 26 and members 20, and also supportsthe communication 14 of the data between the members 20.

Referring again to FIG. 2, the devices 101 can also have a userinterface 202, coupled to the device infrastructure 204 by connection222, to interact with a user (e.g. vendor 20, customer 20, nonmember 20,etc.). The user interface 202 can include one or more user input devicessuch as but not limited to a QWERTY keyboard, a keypad, a track wheel, astylus, a mouse, a microphone and the user output device such as an LCDscreen display and/or a speaker. If the screen is touch sensitive, thenthe display can also be used as the user input device as controlled bythe device infrastructure 204. For example, the user interface 202 forthe devices 101 used by the members 20 can be configured to interactwith the members 20 web browsers (applications 16) to access 14 themember information 15 available on the websites/accounts 9 of themembers 20. For the devices 101 used by the members 20,e user interfaces202 can be used to access the administration system 26 (e.g. via awebsite) to register with the system 26 (i.e. set up/modify theiraccount) as well as to provide information for display on their account9. For the devices 101 used by the administration system 26 (e.g. usingthe relationship engine 100), the user interfaces 202 can be used to theadministration to configure the relationship data 1 of member pairing(s)12 based on information and/or registration data of the members 20.

Referring again to FIG. 2, operation or the device 101 is facilitated bythe device infrastructure 204. The device infrastructure 204 includesone or more computer processors 208 and can include an associated memory210 (e.g. a random access memory) for storing of relationship data 15and for processing communications 14 communicated between the members 20and between the administration system 26 and the members 20. Thecomputer processor 208 facilitates performance of the device 101configured for the intended task (e.g. members 20, administration system26) through operation of the network interface 200, the user interface202 and other application programs/hardware 16 of the device 101 byexecuting task related instructions. These task related instructions canbe provided by an operating system, and/or software applications 16located in the memory 210, and/or by operability that is configured intothe electronic/digital circuitry of the processor(s) 208 designed toperform the specific task(s). Further, it is recognized that the deviceinfrastructure 204 can include a computer readable storage medium 212coupled to the processor 208 for providing instructions to the processor208 and/or to load/update client applications 16. The computer readablemedium 212 can include hardware and/or software such as, by way ofexample only, magnetic disks, magnetic tape, optically readable mediumsuch as CD/DVD ROMS, and memory cards. In each case, the computerreadable medium 212 may take the form of a small disk, floppy diskette,cassette, hard disk drive, solid state memory card, or RAM provided inthe memory module 210. It should be noted that the above listed examplecomputer readable mediums 212 can be used either alone or incombination. For example, the applications 16 can include browsers usedby the members 20 to access the Web site of the administration system 26and/or to communicate 14 information between members 20 of the system 26

Further, it is recognized that the computing devices 101 can include theexecutable applications 16 comprising code or machine readableinstructions for implementing predetermined functions/operationsincluding those of an operating system, relationship configurationsystem(s), for example, in response to user command or input. Theprocessor 208 as used herein is a configured device and/or set ofmachine-readable instructions for performing operations as described byexample above. As used herein, the processor 208 may comprise any one orcombination of, hardware, firmware, and/or software. The processor 208acts upon information by manipulating, analyzing, modifying, convertingor transmitting information for use by an executable procedure or aninformation device, and/or by routing the information with respect to anoutput device. The processor 208 may use or comprise the capabilities ofa controller or microprocessor, for example. Accordingly, any of thefunctionality (e.g. engine 100) provided by the systems and process ofFIGS. 1,2,3 may be implemented in hardware, software or a combination ofboth. Accordingly, the use of a processor 208 as a device and/or as aset of machine readable instructions is hereafter referred togenerically as a processor/module for sake of simplicity. Further, it isrecognized that the administration system 26 can include one or more ofthe computing devices 301 (comprising hardware and/or software) forimplementing the engine 100, as desired.

It will be understood that the member 20 client computing devices 101may be, for example, personal computers, personal digital assistants,mobile phones, and content players. Server computing devices 101 (e.g.for the administration system 26 and/or the member 20) may additionallyinclude a secondary storage element such as the memory (e.g. database).Each server, although depicted as a single computer system, may beimplemented as a network of computer processors, as desired.

I claim:
 1. A computer-implemented method for evolving, at arelationship administration system, a defined online existingrelationship between a first member and a second member, the onlineexisting relationship defined by a plurality of existing relationshipfeatures for use in managing network interaction on a communicationsnetwork between the first member and the second member, the methodcomprising the steps of: receiving a new online relationship having newrelationship features such that the new relationship features aredifferent from the existing relationship features, the new relationshipfeatures being characteristic of the new relationship; aggregating theexisting relationship features and the new relationship features asaggregate relationship features by combining the existing relationshipfeatures and the new relationship features in order to define anaggregate relationship; storing the aggregate relationship features in astorage as relationship data in a relationship matrix representing theaggregate relationship defined by the aggregate relationship features,the aggregate relationship features comprising of aggregate first rolefeatures of the first member and aggregate second role features of thesecond member, the aggregate first role features being different fromthe aggregate second role features in that the aggregate first rolefeatures define at least one of message content, or message type aspermitted by the first member in a first network message while theaggregate second role features omit or otherwise deny said at least oneof the message content or message type from a second network message bythe second member; and accessing the relationship matrix to obtain therelationship data in order to determine whether a selected networkmessage initiated by the first member for communication over thecommunications network for receipt by the second member is permitted inview of at least one of the corresponding aggregate relationshipfeatures of the aggregate relationship, and either allowing or denyingto allow or deny the selected second network message to be communicatedover the communications network from the first second member to thesecond member based on the relationship data, the second message havingsaid at least one of the message content or message type as apresentation on a user interface of the first member; wherein said atleast one of the corresponding aggregate relationship features of theaggregate relationship is used to define at least one of message type,message content, or and message format of the selected first networkmessage and the second network message.
 2. The method of claim 1,wherein the aggregate relationship features are shared between the firstmember and the second member.
 3. The method of claim 2, wherein a firstportion of the aggregate relationship features is assigned to a firstaggregate relationship role of the aggregate relationship for the firstmember and a second portion of the aggregate relationship features isassigned to a second aggregate relationship role of the aggregaterelationship for the second member.
 4. The method of claim 3, whereinthe first aggregate relationship role and the second aggregaterelationship role are different, such that the first portion of theaggregate relationship features characterizes the first aggregaterelationship role and the second portion of the aggregate relationshipfeatures characterizes the second aggregate relationship role, such thatthe first aggregate relationship role and the second aggregaterelationship role are part of the aggregate relationship defined as anaggregate relationship pair between the first and second members.
 5. Acomputer-implemented method for evolving, at a relationshipadministration system, a defined online existing relationship pairbetween a first member and a second member, the online existingrelationship pair defined by a first existing relationship role assignedto the first member having a plurality of first existing role featuresfor use in managing network interaction on a communications networkbetween the first member and the second member, and a second existingrelationship role assigned to the second member having a plurality ofsecond existing role features for use in managing the networkinteraction between the first member and the second member, the methodcomprising the steps of: receiving a new online relationship pair havinga first new relationship role and a second new relationship role, suchthat corresponding first new role features of the first new relationshiprole and the second new role features of the second new relationshiprole are different from the first existing role features and the secondexisting role features, the first new role features and the second newrole features being characteristic of the new relationship pair;aggregating the first existing role features and the first new rolefeatures as aggregate first role features by combining the firstexisting role features and the first new role features in order todefine a first aggregate role; aggregating the second existing rolefeatures and the second new role features as second aggregate rolefeatures by combining the second existing role features and the secondnew role features in order to define a second aggregate role; storingthe first aggregate role and the second aggregate role with theirassociated aggregate features in a storage as relationship data in arelationship matrix representing an aggregate relationship pair definedby the first and second aggregate roles and their correspondingaggregate role features, the aggregate first role features beingdifferent from the aggregate second role features in that the aggregatefirst role features define at least one of message content or messagetype as permitted by the first member in a first network message whilethe aggregate second role features omit or otherwise deny said at leastone of the message content or message type from a second network messageby the second member; and accessing the relationship matrix to obtainthe relationship data in order to determine whether a selected networkmessage initiated by the first member for communication over thecommunications network for receipt by the second member is permitted inview of at least one of the first or second aggregate roles or theirassociated aggregate role features of at least one of the firstaggregate role or the second aggregate role of the aggregaterelationship pair, and either allowing or denying to allow or deny theselected second network message to be communicated over thecommunications network from the first member to the second member basedon the relationship data, the second message having said at least one ofthe message content or message type as a presentation on a userinterface of the first member; wherein said at least one of thecorresponding aggregate role or aggregate role features of at least oneof the first aggregate role or the second aggregate role of theaggregate relationship pair is used to define at least one of messagetype, message content, or and message format of the selected firstnetwork message and the second network message.
 6. The method of claim5, wherein the step of aggregating the first existing and first new rolefeatures involves the addition of a new feature from the first new rolefeatures to the first existing role features.
 7. The method of claim 5,wherein the step of aggregating the first existing and first new rolefeatures involves the deletion of an existing feature from the existingrole features.
 8. The method of claim 5, wherein the step of aggregatingthe first existing and first new role features involves the substitutionof a new feature from the first new role features exchange an existingfeature of the existing role features.
 9. The method of claim 6, whereinthe network message includes a network action associated with a profileof at least one of the first member or the second member.
 10. The methodof claim 6 further comprising the step of defining a minimum number ofthe first existing role features to remain as part of the firstaggregate role features.
 11. The method of claim 10 further comprisingthe step of defining a minimum number of the first new role features tobecome part of the first aggregate role features.
 12. The method ofclaim 10 further comprising the step of defining in the saidrelationship data that the aggregate relationship pair is an activerelationship pair that requires formal acceptance by the second memberof the second new relationship role.
 13. The method of claim 10 furthercomprising the step of defining in the said relationship data that theaggregate relationship pair is a passive relationship pair that does notrequire formal acceptance by the second member of the second newrelationship role.
 14. The method of claim 10 further comprising thestep of defining the first new relationship role and the second newrelationship role as directional roles, such that the first member mustassume the first new relationship role in order for the second member toassume the second new relationship role.
 15. The method of claim 14,wherein the first new role features and the second new role features aredifferent from one another.
 16. The method of claim 6 further comprisingthe step of defining in the said relationship data that the aggregaterelationship pair is an active relationship pair that requires formalacceptance by the second member of the second new relationship role. 17.The method of claim 6 further comprising the step of defining in thesaid relationship data that the aggregate relationship pair is a passiverelationship pair that does not require formal acceptance by the secondmember of the second new relationship role.
 18. The method of claim 10further comprising the step of defining the first new relationship roleand the second new relationship role as directional roles, such that thefirst member must assume the first new relationship role in order forthe second member to assume the second new relationship role.
 19. Themethod of claim 18, wherein the first new role features and the secondnew role features are different from one another.
 20. Acomputer-implement method for evolving, at a relationship administrationsystem, a defined online existing relationship pair between a firstmember and a second member, the online existing relationship pairdefined by a plurality of existing relationship features for use inmanaging network interaction on a communications network between thefirst member and the second member, the method comprising the steps of:receiving a new online relationship pair having corresponding newrelationship features different from the existing relationship features,the new relationship features such that being characteristic of the newrelationship pair; combining the existing relationship features and thenew relationship features to generate combined relationship features byadding a new feature from the new relationship features to the existingrelationship features, such that a minimum number of the existingrelationship features remain as part of the combined relationshipfeatures, the combined relationship features comprising combined firstrole features of the first member and combined second role features ofthe second member; storing the combined relationship features in astorage as relationship data in a relationship matrix representing thenew relationship pair for the first and second members defined by thecorresponding respective combined relationship features, the combinedfirst role features being different from the combined second rolefeatures in that the combined first role features define at least one ofmessage content or message type as permitted by the first member in afirst network message while the combine second role features omit orotherwise deny said at least one of the message content or message typefrom a second network message by the second member; and accessing therelationship matrix to obtain the relationship data in order todetermine whether a selected network message initiated by the firstmember for communication over the communications network for receipt bythe second member is permitted in view of at least one of thecorresponding combined relationship features, and either allowing ordenying to allow or deny the selected second network message to becommunicated over the communications network from the first secondmember to the second member based on the relationship data, the secondmessage having said at least one of the message content or message typeas a presentation on a user interface of the first member; wherein atleast one of the corresponding combined relationship features of the newrelationship pair is used to define at least one of message type,message content, or and message format of the selected first networkmessage and the second network message.
 21. A computer-implementedmethod for evolving, at a relationship administration system, a definedonline existing relationship pair between a first member and a secondmember, the online existing relationship pair defined by a firstexisting relationship role assigned to the first member having aplurality of first existing role features for use in managing networkinteraction on a communications network between the first member and thesecond member, and a second existing relationship role assigned to thesecond member having a plurality of second existing role features foruse in managing the network interaction between the first member and thesecond member, the method comprising the steps of: receiving a newonline relationship pair having a corresponding first new role featuresand second new role features different from the first existing rolefeatures and second existing role features, the first new role featuresand second new role features being characteristic of the newrelationship pair; combining the first existing role features and thefirst new role features to generate first combined first role featuresby adding a new feature from the first new role features to the firstexisting role features, such that a minimum number of the first existingrole features remain as part of the first combined first role features;combining the second existing role features and the second new rolefeatures to generate second combined second role features by adding anew feature from the second new role features to the second existingrole features, such that a minimum number of the second existing rolefeatures remain as part of the second combined second role features;storing the first and second combined role features in a storage asrelationship data in a relationship matrix representing the newrelationship pair for the first and second members defined by thecorresponding respective first and second combined role features, thecombined first role features being different from the combined secondrole features in that the combined first role features define at leastone of message content or message type as permitted by the first memberin a first network message while the combine second role features omitor otherwise deny said at least one of the message content or messagetype from a second network message by the second member; and accessingthe relationship matrix to obtain the relationship data in order todetermine whether a selected network message initiated by the firstmember for communication over the communications network for receipt bythe second member is permitted in view of at least one of thecorresponding first or second combined role features, and eitherallowing or denying to allow or deny the selected second network messageto be communicated over the communications network from the first secondmember to the second member based on the relationship data, the secondmessage having said at least one of the message content or message typeas a presentation on a user interface of the first member; wherein atleast one of the corresponding first or second combined role features ofthe new relationship pair is used to define at least one of messagetype, message content, or and message format of the selected firstnetwork message and the second network message.
 22. The method of claim21 further comprising the step of defining a minimum number of the firstnew role features to become part of the first combined role features.23. The method of claim 21 further comprising the step of defining aminimum number of the second new role features to become part of thesecond combined role features.
 24. A computer implemented method fordefining, at a relationship administration system, an onlinerelationship pair between a first member and a second member, therelationship pair including a first relationship role assigned to thefirst member having a plurality of first role features for use inmanaging network interaction on a communications network between thefirst member and the second member, and a second relationship roleassigned to the second member having a plurality of second role featuresfor use in managing the network interaction between the first member andthe second member, the method comprising the steps of: assigning thefirst relationship role to the first member such that the first rolefeatures are characteristic of the first relationship role; assigningthe second relationship role to the second member such that the secondrole features are characteristic of the second relationship role, suchthat the second member must confirm the second relationship role inorder for the first member to be able to use the first relationship rolein the network interaction between the first and second members; storingthe first relationship role and the second relationship role with theirassociated role features in a storage as relationship data in arelationship matrix representing the relationship pair, the first rolefeatures being different from the second role features in that the firstrole features define at least one of message content, or message type aspermitted by the first member in a first network message while thesecond role features omits or otherwise denies said at least one of themessage content or message type from a second network message by thesecond member; and accessing the relationship matrix to obtain therelationship data in order to determine whether a selected networkmessage initiated by the first member for communication over thecommunications network for receipt by the second member is permitted inview of at least one of the corresponding relationship roles or rolefeatures of at least one of the first relationship role or secondrelationship role of the relationship pair, and either allowing ordenying to allow or deny the selected second network message to becommunicated over the communications network from the first secondmember to the second member based on the relationship data, the secondmessage having said at least one of the message content or message typeas a presentation on a user interface of the first member; wherein saidat least one of the corresponding first or second relationship roles orrole features of at least one of the first relationship role or thesecond relationship role of the relationship pair is used to define atleast one of message type, message content, or and message format of theselected first network message and the second network message.
 25. Acomputer-implemented method for deciding, at a relationshipadministration system, an online relationship pair between a firstmember and a second member, the method comprising the steps of:informing a first relationship role of the online relationship pair as apotential to the first member, the first relationship role comprising aplurality of first role features; receiving confirmation of the firstrelationship role; informing a second relationship role of the onlinerelationship pair as a potential to the second member, the secondrelationship role comprising a plurality of second role features;storing the first relationship role and the second relationship rolebetween the first member and the second member as relationship data in arelationship matrix representing a defined relationship pair, the firstrole features being different from the second role features in that thefirst role features define at least one of message content, or messagetype as permitted by the first member in a first network message by thefirst member while the second role features omit or otherwise deny saidat least one of the message content or message type from a secondnetwork message by the second member; and accessing the relationshipmatrix to obtain the relationship data in order to determine whether toallow or deny the second network message communicated over thecommunications network from the second member based on said relationshipdata, the second message having said at least one of the message contentor message type as a presentation on a user interface of the firstmember; said at least one of the corresponding first or secondrelationship roles or the plurality of first role features or theplurality of second role features of the defined relationship pair isused to define at least one of network interaction type, networkinteraction content, or network interaction format of the first networkmessage and the second network message.
 26. The method of claim 25,wherein the defined relationship pair is a new relationship pair. 27.The method of claim 25, wherein the relationship pair includes the firstrelationship role for the first member having a least one first rolefeature for use in managing network interactions on a communicationsnetwork between the first member and the second member, and the secondrelationship role for the second member having at least one second rolefeature for use in managing the network interactions between the secondmember and the first member.
 28. The method of claim 25, wherein thesecond member confirms the second relationship role.
 29. Acomputer-implemented method for defining, at a relationshipadministration system, a online relationship pair between a first memberand a second member, the method comprising the steps of: based on afirst relationship role of the online relationship pair for the firstmember, receiving a second relationship role of the online relationshippair for the second member from the first member, the first relationshiprole comprising a plurality of first role features and the secondrelationship role comprising a plurality of second role features;sending the second relationship role of the online relationship pair tothe second member; storing the first relationship role and the secondrelationship role between the first member and the second member asrelationship data in a relationship matrix representing a definedrelationship pair for coordinating subsequent network interactionsbetween the first member and the second member, the first role featuresbeing different from the second role features in that the first rolefeatures define at least one of message content, or message type aspermitted by the first member in a first network message by the firstmember while the second role features omit or otherwise deny said atleast one of the message content or message type from a second networkmessage by the second member; and accessing the relationship matrix toobtain the relationship data in order to determine whether to allow ordeny the second network message communicated over the communicationsnetwork from the second member based on said relationship data, thesecond message having said at least one of the message content ormessage type as a presentation on a user interface of the first member;said at least one of the corresponding first or second relationshiproles or the plurality of first role features or the plurality of secondrole features of the defined relationship pair is used to define atleast one of network interaction type, network interaction content, ornetwork interaction format of the first network message and the secondnetwork message.
 30. The method of claim 29, wherein the networkinteraction is a network message.
 31. The method of claim 30, whereinthe network interaction is initiated by one of the members to the otherof the members.
 32. A computer-implemented method for facilitating, at arelationship administration system, a plurality of different onlinerelationship pairs for selection between a first member and a secondmember, the method comprising the steps of: providing a firstrelationship role of a selected online relationship pair for the firstmember, the first relationship role comprising a plurality of first rolefeatures; providing a second relationship role of the selected onlinerelationship pair for the second member, the second relationship rolecomprising a plurality of second role features; storing the firstrelationship role and the second relationship role between the firstmember and the second member as relationship data in a relationshipmatrix representing a defined relationship pair for coordinatingsubsequent network interactions between the first member and the secondmember, the first role features being different from the second rolefeatures in that the first role features define at least one of messagecontent, or message type as permitted by the first member in a firstnetwork message by the first member while the second relationship rolefeatures omit or otherwise deny said at least one of the message contentor message type from a second network message by the second member; andaccessing the relationship matrix to obtain the relationship data inorder to determine whether to allow or deny the second network messagecommunicated over the communications network from the second memberbased on said relationship data, the second message having said at leastone of the message content or message type as a presentation on a userinterface of the first member; said at least one of the correspondingfirst or second relationship roles or the plurality of first rolefeatures or the plurality of second role features of the definedrelationship pair is used to define at least one of network interactiontype, network interaction content, or network interaction format of thefirst network message and the second network message.
 33. The method ofclaim 32, wherein at least one of the first member or the second memberis a group of members.
 34. The method of claim 32, wherein at least oneof the first member or the second member is paired to a plurality ofmembers.
 35. The method of claim 32, wherein the first member is pairedto a third member.
 36. The method of claim 32, wherein the definedrelationship pair is impacted by time.
 37. The method of claim 32,wherein the defined relationship pair is affected by events triggeringrelationship change.
 38. The method of claim 37, wherein the definedrelationship pair is affected by occurrence of specific member actions.39. The method of claim 32, wherein the first member is a delegate ofthe second member.
 40. The method of claim 32, wherein the definedrelationship pair is one of an active or a passive relationship.
 41. Themethod of claim 25, wherein the defined relationship pair is one of aplurality of different possible relationship pairs between the firstmember and the second member, one of said plurality of differentpossible relationship pairs having different online interactionabilities of an interaction relative to another of said plurality ofdifferent possible relationship pairs, each of the different onlineinteraction abilities of the interaction defining a correspondingconnection option type defining information of the interaction as atleast one of visible or sharable between the first member and the secondmember.
 42. The method of claim 29, wherein the defined relationshippair is one of a plurality of different possible relationship pairsbetween the first member and the second member, one of said plurality ofdifferent possible relationship pairs having different onlineinteraction abilities of an interaction relative to another of saidplurality of different possible relationship pairs, each of thedifferent online interaction abilities of the interaction defining acorresponding connection option type defining information of theinteraction as at least one of visible or sharable between the firstmember and the second member.
 43. The method of claim 32, wherein thedefined relationship pair is one of the plurality of different onlinerelationship pairs between the first member and the second member, oneof said plurality of different possible relationship pairs havingdifferent online interaction abilities of an interaction relative toanother of said plurality of different possible relationship pairs, eachof the different online interaction abilities of the interactiondefining a corresponding connection option type defining information ofthe interaction as at least one of visible or sharable between the firstmember and the second member.